Parameter · Query Tuning / Planner Cost Constants
random_page_cost
Sets the planner's estimate of the cost of a nonsequentially fetched disk page.
- Default:
4 - Type: real
- Range: 0 … 1.79769e+308
- Applies: Session (any user)
In plain words
This is how expensive the planner thinks it is to jump to a random page, compared with reading the next page in order (which costs 1). The default 4 was chosen for spinning disks. On SSDs or well-cached data, a value around 1.1 to 2 makes the planner use indexes more readily.
For DBAs and operators
Index scans, bitmap heap scans and nested-loop inner lookups are priced with random page reads. The value 4.0 already assumes most random reads are cached (the docs explain the real seek-to-sequential ratio on HDDs is around 40, discounted for a 90% cache hit rate). On SSD/NVMe storage random and sequential reads are close, so 1.1 to 1.5 is common.
The planner also uses effective_cache_size to estimate how many repeated page fetches of an index scan are cache hits (Mackert-Lohman formula), so both should be tuned together.
Symptoms of a value that is too high: the planner prefers sequential scans or hash joins over obviously useful indexes, and SET random_page_cost = 1.1 in the session makes the query faster. Too low: index scans that read most of a big table randomly. It can be set per tablespace (ALTER TABLESPACE … SET (random_page_cost = 1.1)). Keep it ≥ seq_page_cost; a lower random cost is allowed but makes little physical sense.
How to change it
Any user can change it for their session with SET.
See it in context
Planner cost model Scan methods B-tree indexes Life of a SELECT
Related parameters
seq_page_cost effective_cache_size cpu_index_tuple_cost effective_io_concurrency