Two Ways to Read
A sequential scan reads every page of a table in order. An index scan walks an index to find matching entries, then fetches each matching row from the heap, usually with random access. Sequential reads are cheap per page; random reads are expensive.
Why the Planner Picks a Seq Scan
The planner estimates cost. When a filter is not selective, meaning it returns a large fraction of rows, an index scan would fetch many scattered pages and lose to a clean sequential pass. The crossover point is often only a few percent of the table.
When the Choice Goes Wrong
- Stale statistics make the planner misjudge how many rows match.
- A low row estimate that is actually high can pick an index scan that thrashes the heap.
- Missing or unusable indexes force a seq scan even on a selective filter.
What to Do
Run ANALYZE to refresh statistics first. Confirm the index is usable for the predicate. Compare the estimated and actual rows in EXPLAIN ANALYZE before assuming the index is the fix.
Key idea
A sequential scan beats an index scan when a query touches a large fraction of rows, so a seq scan is often a correct planner choice, not a bug.