Minor fixes for the EXPLAIN reference page. Mention the fact that

EXPLAIN ANALYZE can sometimes be significantly slower than running
the same query normally, and make some minor markup improvements.

doc/src/sgml/ref/explain.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.39 2007/01/31 23:26:04 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.40 2007/04/12 22:39:21 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -72,7 +72,7 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac
   <important>
    <para>
     Keep in mind that the statement is actually executed when
-    <literal>ANALYZE</literal> is used.  Although
+    the <literal>ANALYZE</literal> option is used.  Although
     <command>EXPLAIN</command> will discard any output that a
     <command>SELECT</command> would return, other side effects of the
     statement will happen as usual.  If you wish to use
@@ -141,23 +141,33 @@ ROLLBACK;
   <para>
    In order to allow the <productname>PostgreSQL</productname> query
    planner to make reasonably informed decisions when optimizing
-   queries, the <command>ANALYZE</command> statement should be run to
+   queries, the <xref linkend="sql-analyze" endterm="sql-analyze-title">
-   record statistics about the distribution of data within the
+   statement should be run to record statistics about the distribution
-   table. If you have not done this (or if the statistical
+   of data within the table. If you have not done this (or if the
-   distribution of the data in the table has changed significantly
+   statistical distribution of the data in the table has changed
-   since the last time <command>ANALYZE</command> was run), the
+   significantly since the last time <command>ANALYZE</command> was
-   estimated costs are unlikely to conform to the real properties of
+   run), the estimated costs are unlikely to conform to the real
-   the query, and consequently an inferior query plan might be chosen.
+   properties of the query, and consequently an inferior query plan
+   might be chosen.
   </para>
 
   <para>
-   Genetic query optimization (<acronym>GEQO</acronym>) randomly 
+   Genetic query optimization (<acronym>GEQO</acronym>) randomly tests
-   tests execution plans.  Therefore, when the number of tables exceeds
+   execution plans.  Therefore, when the number of join relations
-   <varname>geqo_threshold</> causing genetic query optimization to be 
+   exceeds <xref linkend="guc-geqo-threshold"> causing genetic query
-   used, the execution plan is likely to change each time the statement
+   optimization to be used, the execution plan is likely to change
-   is executed.
+   each time the statement is executed.
   </para>
 
+  <para>
+   In order to measure the runtime cost of each node in the execution
+   plan, the current implementation of <command>EXPLAIN
+   ANALYZE</command> can add considerable profiling overhead to query
+   execution. As a result, running <command>EXPLAIN ANALYZE</command>
+   on a query can sometimes take significantly longer than executing
+   the query normally. The amount of overhead depends on the nature of
+   the query.
+  </para>
  </refsect1>
 
  <refsect1>
@@ -194,8 +204,8 @@ EXPLAIN SELECT * FROM foo WHERE i = 4;
   </para>
 
   <para>
-   And here is an example of a query plan for a query
+   Here is an example of a query plan for a query using an aggregate
-   using an aggregate function:
+   function:
 
 <programlisting>
 EXPLAIN SELECT sum(i) FROM foo WHERE i &lt; 10;