PostgreSQL documentation removes long-standing random_page_cost SSD guidance

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.