Parameter · Query Tuning / Planner Cost Constants
seq_page_cost
Sets the planner's estimate of the cost of a sequentially fetched disk page.
- Default:
1 - Type: real
- Range: 0 … 1.79769e+308
- Applies: Session (any user)
In plain words
The planner does not measure time; it adds up "cost units". Reading one page in order is the reference price, 1 by default. All other prices are relative to it. Lowering it makes full-table reads look cheaper.
For DBAs and operators
A sequential scan costs pages × seq_page_cost + rows × (cpu_tuple_cost + operators × cpu_operator_cost). For the 200,000-row test table of 2,273 pages that is 2,273 + 2,000 = 4,273, exactly what EXPLAIN shows (4,773 with a WHERE clause adding 200,000 × 0.0025).
What matters is the ratio to random_page_cost, and to the CPU costs. If the whole database lives in RAM, lowering both page costs (for example seq_page_cost = 0.1, random_page_cost = 0.1) makes CPU costs relatively more important, which is closer to reality. Changing only seq_page_cost moves the boundary between sequential and index scans.
It can be set per tablespace (ALTER TABLESPACE fast SET (seq_page_cost = 0.5)), which is the right tool when some tables are on faster storage. Cost constants are planner hints: they change which plan is chosen, never how fast the disk is. Always verify with EXPLAIN ANALYZE.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
random_page_cost cpu_tuple_cost effective_cache_size enable_seqscan