random_page_cost

random_page_cost tells the planner how expensive a random (scattered) page fetch is relative to a sequential read (seq_page_cost = 1.0). It heavily influences index-vs-sequential-scan choices: a high value makes random index lookups look expensive and biases toward sequential scans.

The default 4.0 reflects spinning disks. On SSDs and especially NVMe, random reads are nearly as cheap as sequential, so lowering it to ~1.1–1.5 makes the planner correctly prefer index scans where they help. It's a planner-only knob and can be set per session.

What the number means

The planner costs every plan in abstract "cost units." Two of the anchors are:

• seq_page_cost = 1.0 — the cost of reading one page sequentially.
• random_page_cost = 4.0 (default) — the cost of reading one page at a random location.

So out of the box the planner assumes a random page fetch is four times as expensive as a sequential one. That ratio is the disk-era reality: a spinning disk had to physically seek for random reads.

Why the default hurts on SSD/NVMe

On flash storage there's no seek — random reads are almost as fast as sequential. Leaving random_page_cost at 4.0 makes the planner over-estimate the cost of index scans (which do many random fetches) and drift toward sequential scans, even when an index would win.

Lowering it corrects that bias:

-- SSD
SET random_page_cost = 1.5;
-- NVMe / well-cached
SET random_page_cost = 1.1;

Many cloud Postgres images already ship a lowered value for this reason.

How to tell it's wrong

If EXPLAIN shows the planner choosing a Seq Scan with a selective filter on an indexed column — and forcing the index (or lowering random_page_cost) makes the query much faster — the cost ratio is mis-calibrated for your storage.

It's a planner-only knob (no memory or I/O cost) and can be set per session, so it's safe to experiment with on a single query first:

SET LOCAL random_page_cost = 1.1;
EXPLAIN (ANALYZE) SELECT … ;

Don't forget effective_cache_size

random_page_cost and effective_cache_size jointly drive index-vs-seq-scan. If much of your data is cached, set effective_cache_size realistically high as well — both signal to the planner that index access is cheap.

• Index Scan
• Bitmap Heap Scan
• Sequential Scan

What should random_page_cost be on SSD/NVMe?

Around 1.1–1.5. Flash storage makes random reads almost as cheap as sequential, so the disk-era default of 4.0 over-penalizes index scans and can push the planner toward unnecessary sequential scans.

• seq_page_cost
• effective_cache_size
• effective_io_concurrency