Index: doc/src/sgml/arch-dev.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/arch-dev.sgml,v retrieving revision 2.21 diff -c -r2.21 arch-dev.sgml *** doc/src/sgml/arch-dev.sgml 22 Jun 2003 16:16:44 -0000 2.21 --- doc/src/sgml/arch-dev.sgml 13 Sep 2003 22:05:17 -0000 *************** *** 25,31 **** 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. --- 25,31 ---- 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 ! at which the results are returned to the client. *************** *** 79,85 **** The planner/optimizer takes ! the (rewritten) querytree and creates a query plan that will be the input to the executor. --- 79,85 ---- The planner/optimizer takes ! the (rewritten) query tree and creates a query plan that will be the input to the executor. *************** *** 183,194 **** 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. --- 183,194 ---- 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. The parser and lexer are ! implemented using the well-known Unix tools yacc ! and lex. *************** *** 201,223 **** ! 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 or yacc is called. --- 201,222 ---- ! 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 or yacc is called. *************** *** 334,347 **** 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. ! After the cheapest path is determined, a plan tree --- 333,358 ---- Planner/Optimizer ! 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 *************** *** 373,379 **** 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 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 --- 384,390 ---- 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 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,432 **** ! 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. --- 427,445 ---- ! 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. Index: doc/src/sgml/geqo.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/geqo.sgml,v retrieving revision 1.23 diff -c -r1.23 geqo.sgml *** doc/src/sgml/geqo.sgml 20 Jan 2002 22:19:56 -0000 1.23 --- doc/src/sgml/geqo.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 28,34 **** 1997-10-02 ! Genetic Query Optimization --- 28,34 ---- 1997-10-02 ! Genetic Query Optimizer *************** *** 44,67 **** 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. 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. --- 44,72 ---- 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. The current PostgreSQL optimizer ! 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,86 **** Performance difficulties in exploring the space of possible query ! plans created the demand for a new optimization technique being developed. ! In the following we propose the implementation of a Genetic Algorithm ! as an option for the database query optimization problem. --- 80,93 ---- Performance difficulties in exploring the space of possible query ! plans created the demand for a new optimization technique to be developed. ! 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,217 **** ! 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; --- 215,224 ---- ! 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; Index: doc/src/sgml/gist.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/gist.sgml,v retrieving revision 1.11 diff -c -r1.11 gist.sgml *** doc/src/sgml/gist.sgml 9 Jan 2002 00:52:37 -0000 1.11 --- doc/src/sgml/gist.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 1,3 **** --- 1,7 ---- + + Index: doc/src/sgml/install-win32.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/install-win32.sgml,v retrieving revision 1.11 diff -c -r1.11 install-win32.sgml *** doc/src/sgml/install-win32.sgml 24 Mar 2003 14:32:50 -0000 1.11 --- doc/src/sgml/install-win32.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 1,3 **** --- 1,7 ---- + + Installation on <productname>Windows</productname> Index: doc/src/sgml/libpgtcl.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/libpgtcl.sgml,v retrieving revision 1.37 diff -c -r1.37 libpgtcl.sgml *** doc/src/sgml/libpgtcl.sgml 8 Sep 2003 23:02:28 -0000 1.37 --- doc/src/sgml/libpgtcl.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 1,3 **** --- 1,7 ---- + + <application>pgtcl</application> - Tcl Binding Library Index: doc/src/sgml/page.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/page.sgml,v retrieving revision 1.13 diff -c -r1.13 page.sgml *** doc/src/sgml/page.sgml 19 Feb 2003 04:06:28 -0000 1.13 --- doc/src/sgml/page.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 1,3 **** --- 1,7 ---- + + Page Files Index: doc/src/sgml/reference.sgml =================================================================== RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/reference.sgml,v retrieving revision 1.45 diff -c -r1.45 reference.sgml *** doc/src/sgml/reference.sgml 27 Jun 2003 14:45:25 -0000 1.45 --- doc/src/sgml/reference.sgml 13 Sep 2003 21:58:53 -0000 *************** *** 1,4 **** !