This patch makes a few incremental improvements to geqo.sgml and
arch-dev.sgml
-Neil
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.
</para>
<sect1 id="query-path">
--- 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.
</para>
<sect1 id="query-path">
***************
*** 79,85 ****
<step>
<para>
The <firstterm>planner/optimizer</firstterm> takes
! the (rewritten) querytree and creates a
<firstterm>query plan</firstterm> that will be the input to the
<firstterm>executor</firstterm>.
</para>
--- 79,85 ----
<step>
<para>
The <firstterm>planner/optimizer</firstterm> takes
! the (rewritten) query tree and creates a
<firstterm>query plan</firstterm> that will be the input to the
<firstterm>executor</firstterm>.
</para>
***************
*** 183,194 ****
<title>Parser</title>
<para>
! The parser has to check the query string (which arrives as
! plain ASCII text) for valid syntax. If the syntax is correct a
! <firstterm>parse tree</firstterm> is built up and handed back otherwise an error is
! returned. For the implementation the well known Unix
! tools <application>lex</application> and <application>yacc</application>
! are used.
</para>
<para>
--- 183,194 ----
<title>Parser</title>
<para>
! The parser has to check the query string (which arrives as plain
! ASCII text) for valid syntax. If the syntax is correct a
! <firstterm>parse tree</firstterm> is built up and handed back;
! otherwise an error is returned. The parser and lexer are
! implemented using the well-known Unix tools <application>yacc</>
! and <application>lex</>.
</para>
<para>
***************
*** 201,223 ****
</para>
<para>
! The parser is defined in the file <filename>gram.y</filename> and consists of a
! set of <firstterm>grammar rules</firstterm> and <firstterm>actions</firstterm>
! 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.
</para>
<para>
! The file <filename>scan.l</filename> is transformed to
! the C-source file <filename>scan.c</filename>
! using the program <application>lex</application>
! and <filename>gram.y</filename> is transformed to
! <filename>gram.c</filename> using <application>yacc</application>.
! 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 <application>lex</application>
or <application>yacc</application> is called.
<note>
--- 201,222 ----
</para>
<para>
! The parser is defined in the file <filename>gram.y</filename> and
! consists of a set of <firstterm>grammar rules</firstterm> and
! <firstterm>actions</firstterm> 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.
</para>
<para>
! The file <filename>scan.l</filename> is transformed to the C
! source file <filename>scan.c</filename> using the program
! <application>lex</application> and <filename>gram.y</filename> is
! transformed to <filename>gram.c</filename> using
! <application>yacc</application>. 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 <application>lex</application>
or <application>yacc</application> is called.
<note>
***************
*** 334,347 ****
<title>Planner/Optimizer</title>
<para>
! The task of the <firstterm>planner/optimizer</firstterm> is to create an optimal
! execution plan. It first considers all possible ways of
! <firstterm>scanning</firstterm> and <firstterm>joining</firstterm>
! 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.
! </para>
<para>
After the cheapest path is determined, a <firstterm>plan tree</>
--- 333,358 ----
<title>Planner/Optimizer</title>
<para>
! The task of the <firstterm>planner/optimizer</firstterm> 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.
! </para>
!
! <note>
! <para>
! 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, <productname>PostgreSQL</productname> uses a <xref
! linkend="geqo" endterm="geqo-title">.
! </para>
! </note>
<para>
After the cheapest path is determined, a <firstterm>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 <literal>where rel1.attr1=rel2.attr2</literal>
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 <literal>WHERE</literal> qualification (i.e. for
which a restriction like <literal>where rel1.attr1=rel2.attr2</literal>
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 ****
</para>
<para>
! 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 <firstterm>selection</> (discarding rows that do
! not meet a specified boolean condition) and <firstterm>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.
</para>
</sect2>
</sect1>
--- 427,445 ----
</para>
<para>
! 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 <firstterm>selection</>
! (discarding rows that do not meet a specified boolean condition)
! and <firstterm>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
! <literal>WHERE</literal> clause and computation of required
! output expressions to the most appropriate nodes of the plan
! tree.
</para>
</sect2>
</sect1>
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 ****
<date>1997-10-02</date>
</docinfo>
! <title>Genetic Query Optimization</title>
<para>
<note>
--- 28,34 ----
<date>1997-10-02</date>
</docinfo>
! <title id="geqo-title">Genetic Query Optimizer</title>
<para>
<note>
***************
*** 44,67 ****
<title>Query Handling as a Complex Optimization Problem</title>
<para>
! Among all relational operators the most difficult one to process and
! optimize is the <firstterm>join</firstterm>. 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
! <firstterm>join methods</firstterm>
! (e.g., nested loop, hash join, merge join in <productname>PostgreSQL</productname>) to
! process individual joins and a diversity of
! <firstterm>indexes</firstterm> (e.g., R-tree,
! B-tree, hash in <productname>PostgreSQL</productname>) as access paths for relations.
</para>
<para>
The current <productname>PostgreSQL</productname> optimizer
! implementation performs a <firstterm>near-exhaustive search</firstterm>
! 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.
</para>
<para>
--- 44,72 ----
<title>Query Handling as a Complex Optimization Problem</title>
<para>
! Among all relational operators the most difficult one to process
! and optimize is the <firstterm>join</firstterm>. 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 <firstterm>join
! methods</firstterm> (e.g., nested loop, hash join, merge join in
! <productname>PostgreSQL</productname>) to process individual joins
! and a diversity of <firstterm>indexes</firstterm> (e.g., R-tree,
! B-tree, hash in <productname>PostgreSQL</productname>) as access
! paths for relations.
</para>
<para>
The current <productname>PostgreSQL</productname> optimizer
! implementation performs a <firstterm>near-exhaustive
! search</firstterm> over the space of alternative strategies. This
! algorithm, first introduced in the <quote>System R</quote>
! 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
! <productname>PostgreSQL</productname> query optimizer
! inappropriate for database application domains that involve the
! need for extensive queries, such as artificial intelligence.
</para>
<para>
***************
*** 75,86 ****
<para>
Performance difficulties in exploring the space of possible query
! plans created the demand for a new optimization technique being developed.
</para>
<para>
! In the following we propose the implementation of a <firstterm>Genetic Algorithm</firstterm>
! as an option for the database query optimization problem.
</para>
</sect1>
--- 80,93 ----
<para>
Performance difficulties in exploring the space of possible query
! plans created the demand for a new optimization technique to be developed.
</para>
<para>
! In the following we describe the implementation of a
! <firstterm>Genetic Algorithm</firstterm> to solve the join
! ordering problem in a manner that is efficient for queries
! involving large numbers of joins.
</para>
</sect1>
***************
*** 208,217 ****
<listitem>
<para>
! Usage of <firstterm>edge recombination crossover</firstterm> which is
! especially suited
! to keep edge losses low for the solution of the
! <acronym>TSP</acronym> by means of a <acronym>GA</acronym>;
</para>
</listitem>
--- 215,224 ----
<listitem>
<para>
! Usage of <firstterm>edge recombination crossover</firstterm>
! which is especially suited to keep edge losses low for the
! solution of the <acronym>TSP</acronym> by means of a
! <acronym>GA</acronym>;
</para>
</listitem>
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 ----
+ <!--
+ $Header$
+ -->
+
<Chapter Id="gist">
<DocInfo>
<AuthorGroup>
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 ----
+ <!--
+ $Header$
+ -->
+
<chapter id="install-win32">
<title>Installation on <productname>Windows</productname></title>
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 ----
+ <!--
+ $Header$
+ -->
+
<chapter id="pgtcl">
<title><application>pgtcl</application> - Tcl Binding Library</title>
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 ----
+ <!--
+ $Header$
+ -->
+
<chapter id="page">
<title>Page Files</title>
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 ****
! <!-- reference.sgml
$Header: /var/lib/cvs/pgsql-server/doc/src/sgml/reference.sgml,v 1.45 2003/06/27 14:45:25 petere Exp $
PostgreSQL Reference Manual
--- 1,4 ----
! <!--
$Header: /var/lib/cvs/pgsql-server/doc/src/sgml/reference.sgml,v 1.45 2003/06/27 14:45:25 petere Exp $
PostgreSQL Reference Manual
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
