very extensive. Rather, this chapter is intended to help the reader
understand the general sequence of operations that occur within the
backend from the point at which a query is received, to the point
- when the results are returned to the client.
+ at which the results are returned to the client.
The planner/optimizer takes
- the (rewritten) querytree and creates a
+ the (rewritten) query tree and creates a
query plan that will be the input to the
executor.
Parser
- The parser has to check the query string (which arrives as
- plain ASCII text) for valid syntax. If the syntax is correct a
- parse tree is built up and handed back otherwise an error is
- returned. For the implementation the well known Unix
- are used.
+ The parser has to check the query string (which arrives as plain
+ ASCII text) for valid syntax. If the syntax is correct a
+ parse tree is built up and handed back;
+ otherwise an error is returned. The parser and lexer are
+
implemented using the well-known Unix tools yacc>
- The parser is defined in the file gram.y and consists of a
- set of grammar rules and actions
- that are executed
- whenever a rule is fired. The code of the actions (which
- is actually C-code) is used to build up the parse tree.
+ The parser is defined in the file gram.y and
+ consists of a set of grammar rules and
+ actions that are executed whenever a rule
+ is fired. The code of the actions (which is actually C code) is
+ used to build up the parse tree.
- The file scan.l is transformed to
- the C-source file scan.c
- and gram.y is transformed to
- After these transformations have taken
- place a normal C-compiler can be used to create the
- parser. Never make any changes to the generated C-files as they will
- be overwritten the next time
lex+ The file scan.l is transformed to the C
+ source file scan.c using the program
+ transformed to gram.c using
+
yacc. After these transformations
+ have taken place a normal C compiler can be used to create the
+ parser. Never make any changes to the generated C files as they
+ will be overwritten the next time
lex
Planner/Optimizer
- The task of the planner/optimizer is to create an optimal
- execution plan. It first considers all possible ways of
- scanning and joining
- the relations that appear in a
- query. All the created paths lead to the same result and it's the
- task of the optimizer to estimate the cost of executing each path and
- find out which one is the cheapest.
+ The task of the planner/optimizer is to
+ create an optimal execution plan. A given SQL query (and hence, a
+ query tree) can be actually executed in a wide variety of
+ different ways, each of which will produce the same set of
+ results. If it is computationally feasible, the query optimizer
+ will examine each of these possible execution plans, ultimately
+ selecting the execution plan that will run the fastest.
+
+ In some situations, examining each possible way in which a query
+ may be executed would take an excessive amount of time and memory
+ space. In particular, this occurs when executing queries
+ involving large numbers of join operations. In order to determine
+ a reasonable (not optimal) query plan in a reasonable amount of
+ time,
PostgreSQL uses a
+ linkend="geqo" endterm="geqo-title">.
+
+
+
After the cheapest path is determined, a plan tree
is built to pass to the executor. This represents the desired
After all feasible plans have been found for scanning single relations,
plans for joining relations are created. The planner/optimizer
preferentially considers joins between any two relations for which there
- exist a corresponding join clause in the WHERE qualification (i.e. for
+ exist a corresponding join clause in the WHERE qualification (i.e. for
which a restriction like where rel1.attr1=rel2.attr2
exists). Join pairs with no join clause are considered only when there
is no other choice, that is, a particular relation has no available
- The finished plan tree consists of sequential or index scans of the
- base relations, plus nestloop, merge, or hash join nodes as needed,
- plus any auxiliary steps needed, such as sort nodes or aggregate-function
- calculation nodes. Most of these plan node types have the additional
- ability to do selection (discarding rows that do
- not meet a specified boolean condition) and projection
- (computation of a derived column set based on given column values,
- that is, evaluation of scalar expressions where needed). One of
- the responsibilities of the planner is to attach selection conditions
- from the WHERE clause and computation of required output expressions
- to the most appropriate nodes of the plan tree.
+ The finished plan tree consists of sequential or index scans of
+ the base relations, plus nestloop, merge, or hash join nodes as
+ needed, plus any auxiliary steps needed, such as sort nodes or
+ aggregate-function calculation nodes. Most of these plan node
+ types have the additional ability to do selection
+ (discarding rows that do not meet a specified boolean condition)
+ and projection (computation of a derived column set
+ based on given column values, that is, evaluation of scalar
+ expressions where needed). One of the responsibilities of the
+ planner is to attach selection conditions from the
+ WHERE clause and computation of required
+ output expressions to the most appropriate nodes of the plan
+ tree.
1997-10-02
- >Genetic Query Optimization
+ id="geqo-title">Genetic Query Optimizer
Query Handling as a Complex Optimization Problem
- Among all relational operators the most difficult one to process and
- optimize is the join. The number of alternative plans to answer a query
- grows exponentially with the number of joins included in it. Further
- optimization effort is caused by the support of a variety of
- join methods
- (e.g., nested loop, hash join, merge join in
PostgreSQL) to
- process individual joins and a diversity of
- indexes (e.g., R-tree,
- B-tree, hash in
PostgreSQL) as access paths for relations.
+ Among all relational operators the most difficult one to process
+ and optimize is the join. The number of
+ alternative plans to answer a query grows exponentially with the
+ number of joins included in it. Further optimization effort is
+ caused by the support of a variety of join
+ methods (e.g., nested loop, hash join, merge join in
+
PostgreSQL) to process individual joins
+ and a diversity of indexes (e.g., R-tree,
+ B-tree, hash in
PostgreSQL) as access
+ paths for relations.
The current
PostgreSQL optimizer
- implementation performs a near-exhaustive search
- over the space of alternative strategies. This query
- optimization technique is inadequate to support database application
- domains that involve the need for extensive queries, such as artificial
- intelligence.
+ implementation performs a near-exhaustive
+ search over the space of alternative strategies. This
+ algorithm, first introduced in the System R
+ database, produces a near-optimal join order, but can take an
+ enormous amount of time and memory space when the number of joins
+ in the query grows large. This makes the ordinary
+
PostgreSQL query optimizer
+ inappropriate for database application domains that involve the
+ need for extensive queries, such as artificial intelligence.
Performance difficulties in exploring the space of possible query
- plans created the demand for a new optimization technique being developed.
+ plans created the demand for a new optimization technique to be developed.
- In the following we propose the implementation of a Genetic Algorithm
- as an option for the database query optimization problem.
+ In the following we describe the implementation of a
+ Genetic Algorithm to solve the join
+ ordering problem in a manner that is efficient for queries
+ involving large numbers of joins.
- Usage of edge recombination crossover which is
- especially suited
- to keep edge losses low for the solution of the
+ Usage of edge recombination crossover
+ which is especially suited to keep edge losses low for the
+ solution of the
TSP by means of a
+
+
Installation on <productname>Windows</productname>
+
+
<application>pgtcl</application> - Tcl Binding Library
projects / postgresql.git / commitdiff