Lesson 9 of 12

Bitmap Scans: How PostgreSQL Combines Indexes

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

A plain index scan is great for high selectivity (few rows) and a sequential scan is great for low selectivity (most rows). In between — say 1–15% of a table — both are suboptimal: the index scan jumps around the heap in random order, while the seq scan reads far too much. The bitmap scan fills this gap and is implemented in src/backend/executor/nodeBitmapHeapScan.c and the bitmap index scan nodes.

A bitmap scan trades index order for heap order: it collects all matching row locations first, then reads the heap once in physical block order. That single reordering is what turns thousands of random I/Os into mostly sequential ones — and it’s why bitmaps can also intersect several indexes on the fly.

Two phases

A bitmap scan splits into a Bitmap Index Scan and a Bitmap Heap Scan:

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • Why physical order matters
  • Combining multiple indexes
  • Lossy bitmaps
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • Layer 5 — What an Oracle DBA should expect vs what they get
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 02 — Performance: Query & Index Mastery