random_page_cost

A planner cost constant describing non-sequential page access relative to sequential access. Lowering it makes index and bitmap access paths look cheaper; it does not change storage behavior itself.

Note

Fact — official short description: “Sets the planner’s estimate of the cost of a nonsequentially fetched disk page.”

Identity

Type , Valuereal: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value0 – 1.79769e+308: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Planner Cost Constants: Upstream classification
Latest boot value , Value4: 4

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`4`	—	4

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`1.1`	different	`1.1`
OLAP	`1.1`	different	`1.1`
CRIT	`1.1`	different	`1.1`
TINY	`1.1`	different	`1.1`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 1.1 (dcs); OLAP: PG9.0–19 Beta 3 = 1.1 (dcs); CRIT: PG9.0–19 Beta 3 = 1.1 (dcs); TINY: PG9.0–19 Beta 3 = 1.1 (dcs). Advice, pending human review — Editorial hypothesis, pending maintainer review: 1.1 models SSD random access and cache-heavy deployments as much closer to sequential access.

Common pitfalls

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.

seq_page_cost · effective_cache_size · effective_io_concurrency · default_statistics_target · enable_indexscan · enable_bitmapscan