hardScenarioConceptMidSeniorStaff
A query has an index on the filtered column but the plan shows a sequential scan. Walk me through how you would diagnose it.
3 min readUpdated 2026-08-15
Answer
Short answer
Work outward from the plan: confirm the index is actually usable for the predicate as written, then check whether the optimiser is choosing to ignore it because of selectivity, stale statistics, or a type or collation mismatch that makes the predicate non-sargable.
Was this answer helpful?
Likely follow-ups
- When is a sequential scan genuinely faster than an index scan?
- What is a covering index and how would it change this plan?
- How does column order in a composite index affect which queries can use it?
- How would you confirm the fix rather than assume it worked?
Related questions
- This table has fourteen indexes and writes have got slower. How do you work out which ones to drop?hardAlso on indexing and execution-plan6 min
- Walk me through how you read a PostgreSQL execution plan.mediumAlso on query-optimisation and execution-plan5 min
- A table has forty million rows, thirty-five million of them soft-deleted, and every query for active rows has got slower. Would a partial index help, and what would you have to be careful about?hardAlso on indexing and postgresql5 min
- The same statement takes 20ms in psql and four seconds from the application. Where do you look?hardAlso on query-optimisation and postgresql6 min