From 57a84ca48e8901e77583f0c415f288430f5d66af Mon Sep 17 00:00:00 2001
From: Neil Conway <neilc@samurai.com>
Date: Sun, 22 Jan 2006 03:56:58 +0000
Subject: [PATCH] Minor improvements to GEQO documentation.

---
 doc/src/sgml/geqo.sgml | 38 +++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/doc/src/sgml/geqo.sgml b/doc/src/sgml/geqo.sgml
index 35bb36f22a..a723f4411a 100644
--- a/doc/src/sgml/geqo.sgml
+++ b/doc/src/sgml/geqo.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/geqo.sgml,v 1.34 2005/11/07 17:36:44 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/geqo.sgml,v 1.35 2006/01/22 03:56:58 neilc Exp $
 Genetic Optimizer
 -->
 
@@ -46,8 +46,8 @@ Genetic Optimizer
    <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
+    possible query plans grows exponentially with the
+    number of joins in the query. 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
@@ -57,34 +57,30 @@ Genetic Optimizer
    </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
+    The normal <productname>PostgreSQL</productname> query optimizer
+    performs a <firstterm>near-exhaustive search</firstterm> over the
+    space of alternative strategies. This algorithm, first introduced
+    in IBM's 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
     <productname>PostgreSQL</productname> query optimizer
     inappropriate for queries that join a large number of tables.
    </para>
 
    <para>
     The Institute of Automatic Control at the University of Mining and
-    Technology, in Freiberg, Germany, encountered the described problems as its
-    folks wanted to take the <productname>PostgreSQL</productname> DBMS as the backend for a decision
-    support knowledge based system for the maintenance of an electrical
-    power grid. The DBMS needed to handle large join queries for the
-    inference machine of the knowledge based system.
-   </para>
-
-   <para>
-    Performance difficulties in exploring the space of possible query
-    plans created the demand for a new optimization technique to be developed.
+    Technology, in Freiberg, Germany, encountered some problems when
+    it wanted to use <productname>PostgreSQL</productname> as the
+    backend for a decision support knowledge based system for the
+    maintenance of an electrical power grid. The DBMS needed to handle
+    large join queries for the inference machine of the knowledge
+    based system. The number of joins in these queries made using the
+    normal query optimizer infeasible.
    </para>
 
    <para>
     In the following we describe the implementation of a
-    <firstterm>Genetic Algorithm</firstterm> to solve the join
+    <firstterm>genetic algorithm</firstterm> to solve the join
     ordering problem in a manner that is efficient for queries
     involving large numbers of joins.
    </para>
-- 
2.40.0