vitess.io/vitess@v0.16.2/go/vt/vtgate/planbuilder/doc.go (about) 1 /* 2 Copyright 2019 The Vitess Authors. 3 4 Licensed under the Apache License, Version 2.0 (the "License"); 5 you may not use this file except in compliance with the License. 6 You may obtain a copy of the License at 7 8 http://www.apache.org/licenses/LICENSE-2.0 9 10 Unless required by applicable law or agreed to in writing, software 11 distributed under the License is distributed on an "AS IS" BASIS, 12 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 See the License for the specific language governing permissions and 14 limitations under the License. 15 */ 16 17 /* 18 Package planbuilder allows you to build execution 19 plans that describe how to fulfill a query that may 20 span multiple keyspaces or shards. The main entry 21 points for this package are Build and BuildFromStmt. 22 */ 23 package planbuilder 24 25 /* 26 The main strategy of the planbuilder is to push down as 27 much of the work as possible down to the vttablets. The 28 special primitive for doing this is route, which can 29 execute any SQL on a single shard (or scatter). Any 30 work that cannot be done by a single route is stitched 31 together by VTGate using relational primitives. If 32 stitching is not possible using existing primitives, 33 then an "unsupported" error is returned. 34 35 If a query is split into multiple parts, like a 36 cross-shard join, the latter parts may carry references 37 to the former parts. If this happens, the primitive 38 specifies how to build these cross-shard references as 39 "join variables" that will essentially be sent in 40 as bind vars during execution. For example: 41 42 select ... from a join b on b.col = a.col 43 44 will be executed as: 45 46 select ... a.col from a (produce "a_col" from a.col) 47 select ... from b where b.col = :a_col 48 49 The central design element for analyzing queries and 50 building plans is the symbol table (symtab). This data 51 structure evolves as a query is analyzed. Therefore, 52 searches are not repeatable. To resolve this, search 53 results are persisted inside the ColName as 'Metadata', 54 and reused as needed. 55 56 The plan is built in two phases. In the 57 first phase (break-up and push-down), the query is 58 broken into smaller parts and pushed down into 59 various primitives. In the second phase (wire-up), 60 external references are wired up using bind vars, and 61 the individual ASTs are converted into actual queries. 62 63 In current architecture, VTGate does not know the 64 underlying MySQL schema. Due to this, we assume that 65 any qualified or implicit column reference of a table 66 is valid and we rely on the underlying vttablet/MySQL 67 to eventually validate such references. 68 69 Every 'logicalPlan' primitive must satisfy the logicalPlan 70 interface. This allows the planbuilder to outsource 71 primitive-specific handling into those implementations. 72 73 Variable naming: The AST, planbuilder and engine 74 are three different worlds that use overloaded 75 names that are contextually similar, but different. 76 For example a join is: 77 Join is the AST node that represents the SQL construct 78 join is a logicalPlan in the current package 79 Join is a primitive in the engine package 80 In order to disambiguate, we'll use the 'a' prefix 81 for AST vars, and the 'e' prefix for engine vars. 82 So, 'ajoin' would be of type *sqlparser.Join, and 83 'ejoin' would be of type *engine.Join. For the planbuilder 84 join we'll use 'jb'. 85 */