11<!--
2- $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.2 2000/03/3103:27:41 thomas Exp $
2+ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.3 2000/03/3117:45:00 tgl Exp $
33-->
44
55 <chapter>
@@ -31,7 +31,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.2 2000/03/31 03:27:41 t
3131
3232 <para>
3333 Plan-reading is an art that deserves a tutorial, and I haven't
34- had time to write one. Here is some quick & dirty explanation.
34+ had time to write one. Here is some quick & dirty explanation.
3535 </para>
3636
3737 <para>
@@ -69,9 +69,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.2 2000/03/31 03:27:41 t
6969 </para>
7070
7171 <para>
72- The costs are measured in units of disk page fetches. (There are some
73- fairly bogus fudge-factors for converting CPU effort estimates into
74- disk-fetch units; see the SET ref page if you want to play with these.)
72+ The costs are measured in units of disk page fetches. (CPU effort
73+ estimates are converted into disk-page units using some
74+ fairly arbitrary fudge-factors. See the <command>SET</command>
75+ reference page if you want to experiment with these.)
7576 It's important to note that the cost of an upper-level node includes
7677 the cost of all its child nodes. It's also important to realize that
7778 the cost only reflects things that the planner/optimizer cares about.
@@ -83,7 +84,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.2 2000/03/31 03:27:41 t
8384 </para>
8485
8586 <para>
86- Rows output is a little tricky because it is* not* the number of rows
87+ Rows output is a little tricky because it is<emphasis> not</emphasis> the number of rows
8788 processed/scanned by the query --- it is usually less, reflecting the
8889 estimated selectivity of any WHERE-clause constraints that are being
8990 applied at this node.
@@ -98,7 +99,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.2 2000/03/31 03:27:41 t
9899
99100 <para>
100101 Here are some examples (using the regress test database after a
101- vacuum analyze, andcurrent sources):
102+ vacuum analyze, andalmost-7.0 sources):
102103
103104 <programlisting>
104105regression=# explain select * from tenk1;
@@ -109,7 +110,7 @@ Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
109110 </para>
110111
111112 <para>
112- About as straightforward as it gets. If you do
113+ This is about as straightforward as it gets. If you do
113114
114115 <programlisting>
115116select * from pg_class where relname = 'tenk1';
@@ -131,7 +132,7 @@ NOTICE: QUERY PLAN:
131132Seq Scan on tenk1 (cost=0.00..358.00 rows=1000 width=148)
132133 </programlisting>
133134
134- Estimated output rows has gone down because of the WHERE clause.
135+ The estimate of output rows has gone down because of the WHERE clause.
135136 (The uncannily accurate estimate is just because tenk1 is a particularly
136137 simple case --- the unique1 column has 10000 distinct values ranging
137138 from 0 to 9999, so the estimator's linear interpolation between min and
@@ -191,10 +192,11 @@ Nested Loop (cost=0.00..144.07 rows=100 width=296)
191192
192193 <para>
193194 In this nested-loop join, the outer scan is the same indexscan we had
194- in the example before last, andthe cost and row count are the same
195- because we are applying the "unique1 < 100" WHERE clause atthis node.
195+ in the example before last, andso its cost and row count are the same
196+ because we are applying the "unique1 < 100" WHERE clause atthat node.
196197 The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't
197- affect the row count. For the inner scan, we assume that the current
198+ affect the outer scan's row count. For the inner scan, the
199+ current
198200 outer-scan tuple's unique2 value is plugged into the inner indexscan
199201 to produce an indexqual like
200202 "t2.unique2 = <replaceable>constant</replaceable>". So we get the
@@ -221,7 +223,7 @@ Nested Loop (cost=0.00..144.07 rows=100 width=296)
221223 but it's what we've got at the moment):
222224
223225 <programlisting>
224- regression=# set enable_nestloop =' off' ;
226+ regression=# set enable_nestloop = off;
225227SET VARIABLE
226228regression=# explain select * from tenk1 t1, tenk2 t2 where t1.unique1 < 100
227229regression-# and t1.unique2 = t2.unique2;