random_page_cost

Definition PG 18 manual

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 tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see ALTER TABLESPACE).

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.

Random access to durable storage is normally much more expensive than four times sequential access. However, a lower default is used (4.0) because the majority of random accesses to storage, such as indexed reads, are assumed to be in cache. Also, the latency of network-attached storage tends to reduce the relative overhead of random access.

If you believe caching is less frequent than the default value reflects, and network latency is minimal, you can increase random_page_cost to better reflect the true cost of random storage reads. Storage that has a higher random read cost relative to sequential, like magnetic disks, might also be better modeled with a higher value for random_page_cost. Correspondingly, if your data is likely to be completely in cache, such as when the database is smaller than the total server memory, or network latency is high, decreasing random_page_cost might be appropriate.

How it works

Planner cost units are arbitrary and meaningful mainly in relation to other cost constants. With seq_page_cost conventionally at 1.0, random_page_cost expresses the average penalty of random page access after accounting for expected caching and storage behavior.

Reducing the value relative to seq_page_cost favors index scans; increasing it makes such scans less attractive. Both values can also be overridden per tablespace, which is useful when a cluster spans storage tiers.

The official guidance treats these constants as workload-wide averages and warns against changing them from a few isolated experiments. Plan quality also depends on statistics, effective_cache_size, correlation, and query shape.

Operational considerations

The number is a relative planner cost, not milliseconds or measured device latency.

Lowering it to repair one query can regress the wider workload.

Bad cardinality estimates can be mistaken for incorrect storage costs.

A value below seq_page_cost is normally physically implausible.

A global value can misrepresent mixed SSD, HDD, and network-attached tablespaces.

Workload guidance

OLAP: Do not lower it merely because storage is SSD; analytical scans may still favor sequential access. Calibrate with the full scan-versus-index workload mix and consider tablespace-specific values.

OLTP: On low-latency SSD with a high cache hit rate, 1.1 is a reasonable trial value, not a universal truth. Compare representative EXPLAIN (ANALYZE, BUFFERS) plans and tail latency before adopting it.

SMALL: If the entire database is usually cached, a value near seq_page_cost can be defensible. Avoid setting it below seq_page_cost and fix stale statistics before forcing index-heavy plans.