| The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide
by The PostgreSQL Global Development Group Paperback (6"x9"), 274 pages ISBN 9781906966072 RRP £9.95 ($14.95) Sales of this book support the PostgreSQL project! Get a printed copy>>> |
4.6.2 Planner Cost Constants
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. By default, these cost variables are based on
the cost of sequential page fetches; 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.
Note: 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 receive. 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.
This value can be overridden for a particular tablespace by setting
the tablespace parameter of the same name
(see
ALTER TABLESPACE). 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.
This value can be overridden for a particular tablespace by setting
the tablespace parameter of the same name
(see
ALTER TABLESPACE). Reducing this value relative toseq_page_costwill 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.Tip: Although the system will let you set
random_page_costto less thanseq_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).
| ISBN 9781906966072 | The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide | See the print edition |