From: Bruce Momjian Date: Mon, 29 Sep 2003 18:18:35 +0000 (+0000) Subject: This patch makes a few incremental improvements to geqo.sgml and X-Git-Tag: REL7_4_BETA4~29 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a17b53753e4bd1b5b83e838832505f992d3a4253;p=postgresql This patch makes a few incremental improvements to geqo.sgml and arch-dev.sgml Neil Conway --- diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml index 88ccde9496..73ad8a057e 100644 --- a/doc/src/sgml/arch-dev.sgml +++ b/doc/src/sgml/arch-dev.sgml @@ -1,5 +1,5 @@ @@ -25,7 +25,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg 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. @@ -79,7 +79,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg 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. @@ -183,12 +183,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg 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 - tools lex and yacc - 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 + and lex. @@ -201,23 +201,22 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg - 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 - using the program lex - and gram.y is 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 + The file scan.l is transformed to the C + source file scan.c using the program + lex and gram.y is + 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 or yacc is called. @@ -334,15 +333,27 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg 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 . + + + After the cheapest path is determined, a plan tree is built to pass to the executor. This represents the desired @@ -373,7 +384,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg 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 @@ -416,17 +427,19 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.21 2003/06/22 16:16:44 tg - 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. diff --git a/doc/src/sgml/geqo.sgml b/doc/src/sgml/geqo.sgml index b1d9a9670a..a4622edcf1 100644 --- a/doc/src/sgml/geqo.sgml +++ b/doc/src/sgml/geqo.sgml @@ -1,5 +1,5 @@ @@ -28,7 +28,7 @@ Genetic Optimizer 1997-10-02 - Genetic Query Optimization + Genetic Query Optimizer @@ -44,24 +44,29 @@ Genetic 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. @@ -75,12 +80,14 @@ Genetic Optimizer 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. @@ -208,10 +215,10 @@ Genetic Optimizer - Usage of edge recombination crossover which is - especially suited - to keep edge losses low for the solution of the - TSP by means of a GA; + Usage of edge recombination crossover + which is especially suited to keep edge losses low for the + solution of the TSP by means of a + GA; diff --git a/doc/src/sgml/gist.sgml b/doc/src/sgml/gist.sgml index 386526a3cc..4354d8a4b6 100644 --- a/doc/src/sgml/gist.sgml +++ b/doc/src/sgml/gist.sgml @@ -1,3 +1,7 @@ + + diff --git a/doc/src/sgml/install-win32.sgml b/doc/src/sgml/install-win32.sgml index 96f85d315d..16dfdbdc8f 100644 --- a/doc/src/sgml/install-win32.sgml +++ b/doc/src/sgml/install-win32.sgml @@ -1,3 +1,7 @@ + + Installation on <productname>Windows</productname> diff --git a/doc/src/sgml/libpgtcl.sgml b/doc/src/sgml/libpgtcl.sgml index 70bf66806e..c0ffddebee 100644 --- a/doc/src/sgml/libpgtcl.sgml +++ b/doc/src/sgml/libpgtcl.sgml @@ -1,3 +1,7 @@ + + <application>pgtcl</application> - Tcl Binding Library diff --git a/doc/src/sgml/page.sgml b/doc/src/sgml/page.sgml index 1c501e3d00..6fea43df87 100644 --- a/doc/src/sgml/page.sgml +++ b/doc/src/sgml/page.sgml @@ -1,3 +1,7 @@ + + Page Files