1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>17.6.Query Planning</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="runtime-config.html" title="Chapter17.Server Configuration">
<link rel="prev" href="runtime-config-wal.html" title="17.5.Write Ahead Log">
<link rel="next" href="runtime-config-logging.html" title="17.7.Error Reporting and Logging">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="runtime-config-query"></a>17.6.Query Planning</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="runtime-config-query-enable"></a>17.6.1.Planner Method Configuration</h3></div></div></div>
<p> These configuration parameters provide a crude method of
influencing the query plans chosen by the query optimizer. If
the default plan chosen by the optimizer for a particular query
is not optimal, a temporary solution may be found by using one
of these configuration parameters to force the optimizer to
choose a different plan. Turning one of these settings off
permanently is seldom a good idea, however.
Better ways to improve the quality of the
plans chosen by the optimizer include adjusting the <a href="runtime-config-query.html#runtime-config-query-constants"> Planner Cost Constants
</a>, running <a href="sql-analyze.html">ANALYZE</a> more
frequently, increasing the value of the <a href="runtime-config-query.html#guc-default-statistics-target">default_statistics_target</a> configuration parameter,
and increasing the amount of statistics collected for
specific columns using <code class="command">ALTER TABLE SET
STATISTICS</code>.
</p>
<div class="variablelist"><dl>
<dt>
<a name="guc-enable-bitmapscan"></a><span class="term"><code class="varname">enable_bitmapscan</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of bitmap-scan plan
types. The default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-hashagg"></a><span class="term"><code class="varname">enable_hashagg</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of hashed
aggregation plan types. The default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-hashjoin"></a><span class="term"><code class="varname">enable_hashjoin</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of hash-join plan
types. The default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-indexscan"></a><span class="term"><code class="varname">enable_indexscan</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of index-scan plan
types. The default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-mergejoin"></a><span class="term"><code class="varname">enable_mergejoin</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of merge-join plan
types. The default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-nestloop"></a><span class="term"><code class="varname">enable_nestloop</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of nested-loop join
plans. It's not possible to suppress nested-loop joins entirely,
but turning this variable off discourages the planner from using
one if there are other methods available. The default is
<code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-seqscan"></a><span class="term"><code class="varname">enable_seqscan</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of sequential scan
plan types. It's not possible to suppress sequential scans
entirely, but turning this variable off discourages the planner
from using one if there are other methods available. The
default is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-sort"></a><span class="term"><code class="varname">enable_sort</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of explicit sort
steps. It's not possible to suppress explicit sorts entirely,
but turning this variable off discourages the planner from
using one if there are other methods available. The default
is <code class="literal">on</code>.
</p></dd>
<dt>
<a name="guc-enable-tidscan"></a><span class="term"><code class="varname">enable_tidscan</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables the query planner's use of <acronym class="acronym">TID</acronym>
scan plan types. The default is <code class="literal">on</code>.
</p></dd>
</dl></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="runtime-config-query-constants"></a>17.6.2. Planner Cost Constants
</h3></div></div></div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p> Unfortunately, there is no well-defined method for determining
ideal values for the family of “<span class="quote">cost</span>” variables that
appear below. You are encouraged to experiment and share
your findings.
</p>
</div>
<div class="variablelist"><dl>
<dt>
<a name="guc-effective-cache-size"></a><span class="term"><code class="varname">effective_cache_size</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Sets the planner's assumption about the effective size of the
disk cache that is available to a single index scan. This is
factored into estimates of the cost of using an index; a
higher value makes it more likely index scans will be used, a
lower value makes it more likely sequential scans will be
used. When setting this parameter you should consider both
<span class="productname">PostgreSQL</span>'s shared buffers and the
portion of the kernel's disk cache that will be used for
<span class="productname">PostgreSQL</span> data files. Also, take
into account the expected number of concurrent queries using
different indexes, since they will have to share the available
space. This parameter has no effect on the size of shared
memory allocated by <span class="productname">PostgreSQL</span>, nor
does it reserve kernel disk cache; it is used only for
estimation purposes. The value is measured in disk pages,
which are normally 8192 bytes each. The default is 1000.
</p></dd>
<dt>
<a name="guc-random-page-cost"></a><span class="term"><code class="varname">random_page_cost</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Sets the planner's estimate of the cost of a
nonsequentially fetched disk page. This is measured as a
multiple of the cost of a sequential page fetch. A higher
value makes it more likely a sequential scan will be used, a
lower value makes it more likely an index scan will be
used. The default is four.
</p></dd>
<dt>
<a name="guc-cpu-tuple-cost"></a><span class="term"><code class="varname">cpu_tuple_cost</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Sets the planner's estimate of the cost of processing
each row during a query. This is measured as a fraction of
the cost of a sequential page fetch. The default is 0.01.
</p></dd>
<dt>
<a name="guc-cpu-index-tuple-cost"></a><span class="term"><code class="varname">cpu_index_tuple_cost</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Sets the planner's estimate of the cost of processing
each index row during an index scan. This is measured as a
fraction of the cost of a sequential page fetch. The default
is 0.001.
</p></dd>
<dt>
<a name="guc-cpu-operator-cost"></a><span class="term"><code class="varname">cpu_operator_cost</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Sets the planner's estimate of the cost of processing each
operator in a <code class="literal">WHERE</code> clause. This is measured as a fraction of
the cost of a sequential page fetch. The default is 0.0025.
</p></dd>
</dl></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="runtime-config-query-geqo"></a>17.6.3.Genetic Query Optimizer</h3></div></div></div>
<div class="variablelist"><dl>
<dt>
<a name="guc-geqo"></a><span class="term"><code class="varname">geqo</code> (<code class="type">boolean</code>)</span>
</dt>
<dd><p> Enables or disables genetic query optimization, which is an
algorithm that attempts to do query planning without
exhaustive searching. This is on by default. The
<code class="varname">geqo_threshold</code> variable provides a more
granular way to disable GEQO for certain classes of queries.
</p></dd>
<dt>
<a name="guc-geqo-threshold"></a><span class="term"><code class="varname">geqo_threshold</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> Use genetic query optimization to plan queries with at least
this many <code class="literal">FROM</code> items involved. (Note that an outer
<code class="literal">JOIN</code> construct counts as only one <code class="literal">FROM</code>
item.) The default is 12. For simpler queries it is usually best
to use the deterministic, exhaustive planner, but for queries with
many tables the deterministic planner takes too long.
</p></dd>
<dt>
<a name="guc-geqo-effort"></a><span class="term"><code class="varname">geqo_effort</code>
(<code class="type">integer</code>)</span>
</dt>
<dd>
<p> Controls the trade off between planning time and query plan
efficiency in GEQO. This variable must be an integer in the
range from 1 to 10. The default value is 5. Larger values
increase the time spent doing query planning, but also
increase the likelihood that an efficient query plan will be
chosen.
</p>
<p> <code class="varname">geqo_effort</code> doesn't actually do anything
directly; it is only used to compute the default values for
the other variables that influence GEQO behavior (described
below). If you prefer, you can set the other parameters by
hand instead.
</p>
</dd>
<dt>
<a name="guc-geqo-pool-size"></a><span class="term"><code class="varname">geqo_pool_size</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> Controls the pool size used by GEQO. The pool size is the
number of individuals in the genetic population. It must be
at least two, and useful values are typically 100 to 1000. If
it is set to zero (the default setting) then a suitable
default is chosen based on <code class="varname">geqo_effort</code> and
the number of tables in the query.
</p></dd>
<dt>
<a name="guc-geqo-generations"></a><span class="term"><code class="varname">geqo_generations</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> Controls the number of generations used by GEQO. Generations
specifies the number of iterations of the algorithm. It must
be at least one, and useful values are in the same range as
the pool size. If it is set to zero (the default setting)
then a suitable default is chosen based on
<code class="varname">geqo_pool_size</code>.
</p></dd>
<dt>
<a name="guc-geqo-selection-bias"></a><span class="term"><code class="varname">geqo_selection_bias</code> (<code class="type">floating point</code>)</span>
</dt>
<dd><p> Controls the selection bias used by GEQO. The selection bias
is the selective pressure within the population. Values can be
from 1.50 to 2.00; the latter is the default.
</p></dd>
</dl></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="runtime-config-query-other"></a>17.6.4.Other Planner Options</h3></div></div></div>
<div class="variablelist"><dl>
<dt>
<a name="guc-default-statistics-target"></a><span class="term"><code class="varname">default_statistics_target</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> Sets the default statistics target for table columns that have
not had a column-specific target set via <code class="command">ALTER TABLE
SET STATISTICS</code>. Larger values increase the time needed to
do <code class="command">ANALYZE</code>, but may improve the quality of the
planner's estimates. The default is 10. For more information
on the use of statistics by the <span class="productname">PostgreSQL</span>
query planner, refer to <a href="planner-stats.html" title="13.2.Statistics Used by the Planner">Section13.2, “Statistics Used by the Planner”</a>.
</p></dd>
<dt>
<a name="guc-constraint-exclusion"></a><span class="term"><code class="varname">constraint_exclusion</code> (<code class="type">boolean</code>)</span>
</dt>
<dd>
<p> Enables or disables the query planner's use of table constraints to
optimize queries. The default is <code class="literal">off</code>.
</p>
<p> When this parameter is <code class="literal">on</code>, the planner compares
query conditions with table <code class="literal">CHECK</code> constraints, and
omits scanning tables for which the conditions contradict the
constraints. (Presently this is done only for child tables of
inheritance scans.) For example:
</p>
<pre class="programlisting">CREATE TABLE parent(key integer, ...);
CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
...
SELECT * FROM parent WHERE key = 2400;</pre>
<p>
With constraint exclusion enabled, this <code class="command">SELECT</code>
will not scan <code class="structname">child1000</code> at all. This can
improve performance when inheritance is used to build
partitioned tables.
</p>
<p> Currently, <code class="varname">constraint_exclusion</code> is disabled by
default because it risks incorrect results if query plans are
cached [mdash ] if a table constraint is changed or dropped,
the previously generated plan might now be wrong, and there is
no built-in mechanism to force re-planning. (This deficiency
will probably be addressed in a future
<span class="productname">PostgreSQL</span> release.) Another reason for
keeping it off is that the constraint checks are relatively
expensive, and in many circumstances will yield no savings.
It is recommended to turn this on only if you are actually
using partitioned tables designed to take advantage of the
feature.
</p>
<p> Refer to <a href="ddl-partitioning.html" title="5.9.Partitioning">Section5.9, “Partitioning”</a> for more information
on using constraint exclusion and partitioning.
</p>
</dd>
<dt>
<a name="guc-from-collapse-limit"></a><span class="term"><code class="varname">from_collapse_limit</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> The planner will merge sub-queries into upper queries if the
resulting <code class="literal">FROM</code> list would have no more than
this many items. Smaller values reduce planning time but may
yield inferior query plans. The default is 8. It is usually
wise to keep this less than <a href="runtime-config-query.html#guc-geqo-threshold">geqo_threshold</a>.
</p></dd>
<dt>
<a name="guc-join-collapse-limit"></a><span class="term"><code class="varname">join_collapse_limit</code> (<code class="type">integer</code>)</span>
</dt>
<dd>
<p> The planner will rewrite explicit inner <code class="literal">JOIN</code>
constructs into lists of <code class="literal">FROM</code> items whenever a
list of no more than this many items in total would
result. Prior to <span class="productname">PostgreSQL</span> 7.4, joins
specified via the <code class="literal">JOIN</code> construct would
never be reordered by the query planner. The query planner has
subsequently been improved so that inner joins written in this
form can be reordered; this configuration parameter controls
the extent to which this reordering is performed.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p> At present, the order of outer joins specified via the
<code class="literal">JOIN</code> construct is never adjusted by the query
planner; therefore, <code class="varname">join_collapse_limit</code> has no
effect on this behavior. The planner may be improved to
reorder some classes of outer joins in a future release of
<span class="productname">PostgreSQL</span>.
</p>
</div>
<p>
</p>
<p> By default, this variable is set the same as
<code class="varname">from_collapse_limit</code>, which is appropriate
for most uses. Setting it to 1 prevents any reordering of
inner <code class="literal">JOIN</code>s. Thus, the explicit join order
specified in the query will be the actual order in which the
relations are joined. The query planner does not always choose
the optimal join order; advanced users may elect to
temporarily set this variable to 1, and then specify the join
order they desire explicitly. Another consequence of setting
this variable to 1 is that the query planner will behave more
like the <span class="productname">PostgreSQL</span> 7.3 query
planner, which some users might find useful for backward
compatibility reasons.
</p>
<p> Setting this variable to a value between 1 and
<code class="varname">from_collapse_limit</code> might be useful to
trade off planning time against the quality of the chosen plan
(higher values produce better plans).
</p>
</dd>
</dl></div>
</div>
</div></body>
</html>
|
