↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

Wiki / Plan Nodes / Scan

Bitmap Heap Scan

BitmapHeapScan

Visits heap pages selected by a bitmap and performs required rechecks.

Reading PostgreSQL 18.6.

Description

Visits heap pages selected by a bitmap and performs required rechecks.

Core node tag
T_BitmapHeapScan
Structured EXPLAIN Node Type
Bitmap Heap Scan
Inputs
A tuple-location bitmap and relation
Output
Qualified heap tuples
Executor initializer
ExecInitBitmapHeapScan
Memory mechanism
unclassified

EXPLAIN names and attributes

Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.

Text names recorded by this source: Bitmap Heap Scan.

Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node.

Memory and temporary storage

This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.

If we are using lossy info, we have to recheck the qual conditions at every tuple.

Parallel execution and instrumentation

The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.

Callbacks in this build: ExecBitmapHeapEstimate, ExecBitmapHeapInitializeDSM, ExecBitmapHeapInitializeWorker, ExecBitmapHeapReInitializeDSM, ExecBitmapHeapRetrieveInstrumentation.

Same-version manual discussion

In a parallel bitmap heap scan , one process is chosen as the leader. That process performs a scan of one or more indexes and builds a bitmap indicating which table blocks need to be visited. These blocks are then divided among the cooperating processes as in a parallel sequential scan. In other words, the heap scan is performed in parallel, but the underlying index scan is not.

Examples from this manual build

Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.

Now, let's make the condition more restrictive:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;

                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)
   Recheck Cond: (unique1 < 100)
   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
         Index Cond: (unique1 < 100)

Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.

Now let's add another condition to the WHERE clause:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND stringu1 = 'xxx';

                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=5.04..225.20 rows=1 width=244)
   Recheck Cond: (unique1 < 100)
   Filter: (stringu1 = 'xxx'::name)
   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
         Index Cond: (unique1 < 100)

Executor implementation notes

nodeBitmapHeapscan.c Routines to support bitmapped scans of relations

NOTE: it is critical that this plan type only be used with MVCC-compliant snapshots (ie, regular snapshots, not SnapshotAny or one of the other special snapshots). The reason is that since index and heap scans are decoupled, there can be no assurance that the index tuple prompting a visit to a particular heap TID still exists when the visit is made. Therefore the tuple might not exist anymore either (which is OK because heap_fetch will cope) --- but worse, the tuple slot could have been re-used for a newer tuple. With an MVCC snapshot the newer tuple is certain to fail the time qual and so it will not be mistakenly returned, but with anything else we might return a tuple that doesn't meet the required index qual conditions.

Do the underlying index scan, build the bitmap, set up the parallel state needed for parallel workers to iterate through the bitmap, and set up the underlying table scan descriptor.

The leader will immediately come out of the function, but others will be blocked until leader populates the TBM and wakes them up.

Prepare to iterate over the TBM. This will return the dsa_pointer of the iterator state which will be used by multiple processes to iterate jointly.

EXPLAIN identity in core source

case T_BitmapHeapScan:
			pname = sname = "Bitmap Heap Scan";
			break;

EXPLAIN labels in this source build

Text-format labelStructured node identity
Bitmap Heap ScanBitmap Heap Scan

Related entries

Documentation and source

Source build
Version
18.6
Build
PostgreSQL 18.6 source archive
Source fingerprint
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

Compare versions

PostgreSQL 17 → 18: changed.

--- PostgreSQL 17
+++ PostgreSQL 18
@@ -6,7 +6,8 @@
     "ExecBitmapHeapEstimate",
     "ExecBitmapHeapInitializeDSM",
     "ExecBitmapHeapInitializeWorker",
-    "ExecBitmapHeapReInitializeDSM"
+    "ExecBitmapHeapReInitializeDSM",
+    "ExecBitmapHeapRetrieveInstrumentation"
   ],
   "partial_modes": [],
   "strategies": [],

Compares recorded interfaces and attributes. Source fingerprints and build metadata are excluded; an absent sample is not proof of the introduction or removal release.

Related entries

Export JSON · Back to Plan Nodes · Recorded in PostgreSQL 10 through 20; the first sample is not necessarily its introduction.