A bitmap index scan finds matching entries in an index and records their table locations in a bitmap. PostgreSQL then uses a Bitmap Heap Scan to fetch the referenced rows in bulk, reducing repeated table lookups. section 4.5.2
Read the execution plan as two linked phases:
- Bitmap Index Scan searches the index for entries satisfying the Index Cond and builds row or page-location information. section 4.5.2
- Bitmap Heap Scan visits the table locations recorded in the bitmap and retrieves the requested columns. section 4.5.2
- A bitmap can become lossy under memory pressure, storing matching pages rather than individual rows; PostgreSQL then rechecks conditions during heap access. section 4.5.2 section 5.6.2
Spotting the operation in EXPLAIN
A multi-value filter can produce a plan such as `Bitmap Heap Scan on player_stats` followed by `Bitmap Index Scan on idx_champion_title`. The index phase finds five matching champions, and the heap phase retrieves their rows. A selective equality query may instead use a direct Index Scan, while a low-selectivity predicate can make PostgreSQL choose a sequential scan. section 4.6.1
JSON and full-text search
Bitmap index scans also appear with specialized indexes. A JSON expression index reduces the custom-pizza count from 1.185 ms with a sequential scan to 0.376 ms. GIN indexes use the same two-phase pattern for JSON containment, key-existence, and full-text lexeme searches, with heap rechecks validating candidate rows.
