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  */