Parameter · Query Tuning / Planner Method Configuration
enable_bitmapscan
Enables the planner's use of bitmap-scan plans.
- Default:
on - Type: bool
- Applies: Session (any user)
In plain words
A bitmap scan first asks the index for all matching row locations, sorts them by page, then reads each table page once, in physical order. It sits between an index scan (few rows) and a sequential scan (most rows). Switch it off only to test what the planner would do without it.
For DBAs and operators
The plan has two parts: a Bitmap Index Scan builds an in-memory bitmap of matching TIDs, and a Bitmap Heap Scan visits the pages in block order. Several bitmaps can be combined with BitmapAnd/BitmapOr, which is how PostgreSQL uses two separate indexes for a = 1 OR b = 2.
If the bitmap outgrows work_mem it becomes lossy (one bit per page instead of per row), and every row on those pages is rechecked: EXPLAIN ANALYZE shows Heap Blocks: exact=… lossy=… and Rows Removed by Index Recheck.
On the test table (200,000 rows, about 200 matches) PostgreSQL 18 chose a Bitmap Heap Scan at cost 606; with it disabled it picked an Index Scan at 772; with index scans disabled too, a Seq Scan at 4,773.
Like every enable_* switch, this is not a hard ban. Since PostgreSQL 18 the planner counts disabled nodes and prefers any plan with fewer of them, instead of adding a huge disable_cost. If a disabled bitmap scan is still the only option, it is used and EXPLAIN prints Disabled: true. Use it in a session (SET enable_bitmapscan = off) while diagnosing; setting it globally usually hurts.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
enable_indexscan enable_seqscan work_mem effective_io_concurrency random_page_cost