|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.39 2007/01/31 23:26:04 momjian Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.40 2007/04/12 22:39:21 neilc Exp $ |
3 | 3 | PostgreSQL documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -72,7 +72,7 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac |
72 | 72 | <important> |
73 | 73 | <para> |
74 | 74 | Keep in mind that the statement is actually executed when |
75 | | - <literal>ANALYZE</literal> is used. Although |
| 75 | +the<literal>ANALYZE</literal> option is used. Although |
76 | 76 | <command>EXPLAIN</command> will discard any output that a |
77 | 77 | <command>SELECT</command> would return, other side effects of the |
78 | 78 | statement will happen as usual. If you wish to use |
@@ -141,23 +141,33 @@ ROLLBACK; |
141 | 141 | <para> |
142 | 142 | In order to allow the <productname>PostgreSQL</productname> query |
143 | 143 | planner to make reasonably informed decisions when optimizing |
144 | | - queries, the <command>ANALYZE</command> statement should be run to |
145 | | - record statistics about the distribution of data within the |
146 | | - table. If you have not done this (or if the statistical |
147 | | - distribution of the data in the table has changed significantly |
148 | | - since the last time <command>ANALYZE</command> was run), the |
149 | | - estimated costs are unlikely to conform to the real properties of |
150 | | - the query, and consequently an inferior query plan might be chosen. |
| 144 | + queries, the <xref linkend="sql-analyze" endterm="sql-analyze-title"> |
| 145 | + statement should be run to record statistics about the distribution |
| 146 | + of data within the table. If you have not done this (or if the |
| 147 | + statistical distribution of the data in the table has changed |
| 148 | + significantly since the last time <command>ANALYZE</command> was |
| 149 | + run), the estimated costs are unlikely to conform to the real |
| 150 | + properties of the query, and consequently an inferior query plan |
| 151 | + might be chosen. |
151 | 152 | </para> |
152 | 153 |
|
153 | 154 | <para> |
154 | | - Genetic query optimization (<acronym>GEQO</acronym>) randomly |
155 | | -testsexecution plans. Therefore, when the number oftables exceeds |
156 | | -<varname>geqo_threshold</> causing genetic query optimization to be |
157 | | - used, the execution plan is likely to change each time the statement |
158 | | - is executed. |
| 155 | + Genetic query optimization (<acronym>GEQO</acronym>) randomlytests |
| 156 | + execution plans. Therefore, when the number ofjoin relations |
| 157 | +exceeds <xref linkend="guc-geqo-threshold"> causing genetic query |
| 158 | +optimization to beused, the execution plan is likely to change |
| 159 | +each time the statementis executed. |
159 | 160 | </para> |
160 | 161 |
|
| 162 | + <para> |
| 163 | + In order to measure the runtime cost of each node in the execution |
| 164 | + plan, the current implementation of <command>EXPLAIN |
| 165 | + ANALYZE</command> can add considerable profiling overhead to query |
| 166 | + execution. As a result, running <command>EXPLAIN ANALYZE</command> |
| 167 | + on a query can sometimes take significantly longer than executing |
| 168 | + the query normally. The amount of overhead depends on the nature of |
| 169 | + the query. |
| 170 | + </para> |
161 | 171 | </refsect1> |
162 | 172 |
|
163 | 173 | <refsect1> |
@@ -194,8 +204,8 @@ EXPLAIN SELECT * FROM foo WHERE i = 4; |
194 | 204 | </para> |
195 | 205 |
|
196 | 206 | <para> |
197 | | -And hereis an example of a query plan for a query |
198 | | -using an aggregatefunction: |
| 207 | +Hereis an example of a query plan for a query using an aggregate |
| 208 | + function: |
199 | 209 |
|
200 | 210 | <programlisting> |
201 | 211 | EXPLAIN SELECT sum(i) FROM foo WHERE i < 10; |
|
