Parameter · Query Tuning / Planner Method Configuration
enable_indexscan
Enables the planner's use of index-scan plans.
- Default:
on - Type: bool
- Applies: Session (any user)
In plain words
An index scan walks the index to find matching rows and fetches each one from the table. It is ideal when only a few rows match, or when the index order saves a sort. Switching it off forces the planner to use bitmap scans or read the whole table.
For DBAs and operators
Every matched index entry costs a heap fetch, priced with random_page_cost scaled by the index's correlation with the table order and by effective_cache_size. That is why index scans win for selective lookups and ordered output, and lose to bitmap or sequential scans as the fraction of matching rows grows.
Measured on 18.6, WHERE id = 42 on the primary key: Index Scan, cost 8.44. With enable_indexscan = off: Bitmap Heap Scan (also 8.44, but more steps). With bitmap scans also off: Seq Scan, 4,773. Turning this off also disables index-only scans; it does not affect bitmap scans.
Typical support use: a customer reports that a query ignores an index. SET enable_seqscan = off shows the cost the planner gives the index plan; SET enable_indexscan = off answers the opposite question. Compare the two costs with the real timings from EXPLAIN ANALYZE. If the index plan is really faster but priced higher, look at random_page_cost, effective_cache_size and statistics, not at these switches.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
enable_indexonlyscan enable_bitmapscan enable_seqscan random_page_cost effective_cache_size