# PostgreSQL documentation removes long-standing random_page_cost SSD guidance

> **Key takeaway:** PostgreSQL's documentation was rewritten in October 2025 to remove the 90% cache-hit explanation for random_page_cost=4.0 and the SSD-specific suggestion of 1.1, leaving no official guidance for solid-state storage.

**Published:** 2026-10-18T01:00:00+00:00 
**Source:** Planet PostgreSQL 
**Category:** databases-storage 
**Canonical URL:** https://fosswire.org/news/postgresql-documentation-removes-long-standing-randompagecos.html 

## Summary
Database consultant Christophe Pettus traces how PostgreSQL's random_page_cost parameter actually works in the query planner, correcting widespread misconceptions. The parameter has never measured raw random read speed; it multiplies that cost by cache miss probability. The 4.0 default, set in 2000 for spinning disks, was explained in documentation from 2012-2025 as a 40:1 hardware ratio discounted by 90% cache hits. That explanation and a 2020 SSD recommendation of 1.1 were both removed in October 2025. Recent benchmarks by Tomas Vondra found actual ratios of 20-63 on modern storage, suggesting 4.0 may be too low rather than too high, though methodology disputes remain unresolved and the default stays 4.0 in version 19 beta 4.

## How random_page_cost actually charges index scans
- `random_page_cost` defaults to 4.0, `seq_page_cost` to 1.0; both are floating-point GUCs settable per-tablespace since 9.0
- The planner charges `random_page_cost` per heap page for uncorrelated indexes, interpolating toward `seq_page_cost` as `pg_stats.correlation` approaches 1.0
- For a perfectly correlated index: one random fetch, then sequential cost for remaining pages; for uncorrelated: every distinct heap page at random cost
- Bitmap heap scans slide between the two costs based on square root of table fraction fetched
- Temp-file I/O (spilling sorts, hash aggregates) always uses global values; tablespace overrides do not apply
- PostgreSQL 18 AIO prefetches for sequential and bitmap scans, but through 19 beta 4 plain index scans still issue synchronous heap page requests with no prefetching
- pg_stat_io (16+) and EXPLAIN (ANALYZE, BUFFERS) provide hit/read ratios to tune per-workload

## Why it matters
The documentation change leaves DBAs without official SSD tuning guidance at a time when PostgreSQL 18-19 development is adding asynchronous I/O but not yet for plain index scans. The unresolved debate between Vondra's measured ratios near 20 and Freund's ~4 suggests the community may need to revisit the default before it causes systematic mis-planning on NVMe-backed systems.