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 Planner Cost Constants
, running ANALYZE more
frequently, increasing the value of the default_statistics_target configuration parameter,
and increasing the amount of statistics collected for
specific columns using ALTER TABLE SET
STATISTICS
.
enable_bitmapscan
(boolean
)
Enables or disables the query planner's use of bitmap-scan plan
types. The default is on
.
enable_hashagg
(boolean
)
Enables or disables the query planner's use of hashed
aggregation plan types. The default is on
.
enable_hashjoin
(boolean
)
Enables or disables the query planner's use of hash-join plan
types. The default is on
.
enable_indexscan
(boolean
)
Enables or disables the query planner's use of index-scan plan
types. The default is on
.
enable_mergejoin
(boolean
)
Enables or disables the query planner's use of merge-join plan
types. The default is on
.
enable_nestloop
(boolean
)
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
on
.
enable_seqscan
(boolean
)
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 on
.
enable_sort
(boolean
)
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 on
.
enable_tidscan
(boolean
)
Enables or disables the query planner's use of TID
scan plan types. The default is on
.
The cost variables described in this section are measured
on an arbitrary scale. Only their relative values matter, hence
scaling them all up or down by the same factor will result in no change
in the planner's choices. Traditionally, these variables have been
referenced to sequential page fetches as the unit of cost; that is,
seq_page_cost
is conventionally set to 1.0
and the other cost variables are set with reference to that. But
you can use a different scale if you prefer, such as actual execution
times in milliseconds on a particular machine.
Unfortunately, there is no well-defined method for determining ideal values for the cost variables. They are best treated as averages over the entire mix of queries that a particular installation will get. This means that changing them on the basis of just a few experiments is very risky.
seq_page_cost
(floating point
)
Sets the planner's estimate of the cost of a disk page fetch that is part of a series of sequential fetches. The default is 1.0.
random_page_cost
(floating point
)
Sets the planner's estimate of the cost of a
non-sequentially-fetched disk page. The default is 4.0.
Reducing this value relative to seq_page_cost
will cause the system to prefer index scans; raising it will
make index scans look relatively more expensive. You can raise
or lower both values together to change the importance of disk I/O
costs relative to CPU costs, which are described by the following
parameters.
Although the system will let you set random_page_cost
to
less than seq_page_cost
, it is not physically sensible
to do so. However, setting them equal makes sense if the database
is entirely cached in RAM, since in that case there is no penalty
for touching pages out of sequence. Also, in a heavily-cached
database you should lower both values relative to the CPU parameters,
since the cost of fetching a page already in RAM is much smaller
than it would normally be.
cpu_tuple_cost
(floating point
)
Sets the planner's estimate of the cost of processing each row during a query. The default is 0.01.
cpu_index_tuple_cost
(floating point
)
Sets the planner's estimate of the cost of processing each index entry during an index scan. The default is 0.005.
cpu_operator_cost
(floating point
)
Sets the planner's estimate of the cost of processing each operator or function executed during a query. The default is 0.0025.
effective_cache_size
(integer
)
Sets the planner's assumption about the effective size of the
disk cache that is available to a single query. 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
PostgreSQL's shared buffers and the
portion of the kernel's disk cache that will be used for
PostgreSQL data files. Also, take
into account the expected number of concurrent queries on different
tables, since they will have to share the available
space. This parameter has no effect on the size of shared
memory allocated by PostgreSQL, nor
does it reserve kernel disk cache; it is used only for estimation
purposes. The default is 128 megabytes (128MB
).
geqo
(boolean
)
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
geqo_threshold
variable provides a more
granular way to disable GEQO for certain classes of queries.
geqo_threshold
(integer
)
Use genetic query optimization to plan queries with at least
this many FROM
items involved. (Note that a
FULL OUTER JOIN
construct counts as only one FROM
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.
geqo_effort
(integer
)
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 five. Larger values increase the time spent doing query planning, but also increase the likelihood that an efficient query plan will be chosen.
geqo_effort
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.
geqo_pool_size
(integer
)
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 geqo_effort
and
the number of tables in the query.
geqo_generations
(integer
)
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
geqo_pool_size
.
geqo_selection_bias
(floating point
)
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.
default_statistics_target
(integer
)
Sets the default statistics target for table columns that have
not had a column-specific target set via ALTER TABLE
SET STATISTICS
. Larger values increase the time needed to
do ANALYZE
, but may improve the quality of the
planner's estimates. The default is 10. For more information
on the use of statistics by the PostgreSQL
query planner, refer to Section 13.2, “Statistics Used by the Planner”.
constraint_exclusion
(boolean
)
Enables or disables the query planner's use of table constraints to
optimize queries. The default is off
.
When this parameter is on
, the planner compares
query conditions with table CHECK
constraints, and
omits scanning tables for which the conditions contradict the
constraints. For example:
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;
With constraint exclusion enabled, this SELECT
will not scan child1000
at all. This can
improve performance when inheritance is used to build
partitioned tables.
Currently, constraint_exclusion
is disabled by
default because it risks incorrect results if query plans are
cached — 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
PostgreSQL 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.
Refer to Section 5.9, “Partitioning” for more information on using constraint exclusion and partitioning.
from_collapse_limit
(integer
)
The planner will merge sub-queries into upper queries if the
resulting FROM
list would have no more than
this many items. Smaller values reduce planning time but may
yield inferior query plans. The default is eight. It is usually
wise to keep this less than geqo_threshold.
For more information see Section 13.3, “Controlling the Planner with Explicit JOIN
Clauses”.
join_collapse_limit
(integer
)
The planner will rewrite explicit JOIN
constructs (except FULL JOIN
s) into lists of
FROM
items whenever a list of no more than this many items
would result. Smaller values reduce planning time but may
yield inferior query plans.
By default, this variable is set the same as
from_collapse_limit
, which is appropriate
for most uses. Setting it to 1 prevents any reordering of
explicit JOIN
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.
For more information see Section 13.3, “Controlling the Planner with Explicit JOIN
Clauses”.