BitmapAnd

Description

Intersects bitmaps produced by its child plans.

Core node tag

T_BitmapAnd

Structured EXPLAIN Node Type

BitmapAnd

Inputs

Bitmap-producing child plans

Output

Tuple-location bitmap, not a tuple stream

Executor initializer

ExecInitBitmapAnd

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: BitmapAnd.

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.

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: none extracted from this node implementation.

Same-version manual discussion

BitmapAnd and BitmapOr nodes always report their actual row counts as zero, due to implementation limitations.

Examples from this manual build

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

If there are separate indexes on several of the columns referenced in WHERE , the planner might choose to use an AND or OR combination of the indexes:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;

                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=25.07..60.11 rows=10 width=244)
   Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))
   ->  BitmapAnd  (cost=25.07..25.07 rows=10 width=0)
         ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
               Index Cond: (unique1 < 100)
         ->  Bitmap Index Scan on tenk1_unique2  (cost=0.00..19.78 rows=999 width=0)
               Index Cond: (unique2 > 9000)

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

EXPLAIN has a BUFFERS option which provides additional detail about I/O operations performed during the planning and execution of the given query. The buffer numbers displayed show the count of the non-distinct buffers hit, read, dirtied, and written for the given node and all of its child nodes. The ANALYZE option implicitly enables the BUFFERS option. If this is undesired, BUFFERS may be explicitly disabled:

EXPLAIN (ANALYZE, BUFFERS OFF) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;

                                                           QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=25.07..60.11 rows=10 width=244) (actual time=0.105..0.114 rows=10.00 loops=1)
   Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))
   Heap Blocks: exact=10
   ->  BitmapAnd  (cost=25.07..25.07 rows=10 width=0) (actual time=0.100..0.101 rows=0.00 loops=1)
         ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0) (actual time=0.027..0.027 rows=100.00 loops=1)
               Index Cond: (unique1 < 100)
               Index Searches: 1
         ->  Bitmap Index Scan on tenk1_unique2  (cost=0.00..19.78 rows=999 width=0) (actual time=0.070..0.070 rows=999.00 loops=1)
               Index Cond: (unique2 > 9000)
               Index Searches: 1
 Planning Time: 0.162 ms
 Execution Time: 0.143 ms

Executor implementation notes

NOTES BitmapAnd nodes don't make use of their left and right subtrees, rather they maintain a list of subplans, much like Append nodes. The logic is much simpler than Append, however, since we needn't cope with forward/backward execution.

call ExecInitNode on each of the plans to be executed and save the results into the array "bitmapplanstates".

BitmapAnd plans don't have expression contexts because they never call ExecQual or ExecProject. They don't need any tuple slots either.

If at any stage we have a completely empty bitmap, we can fall out without evaluating the remaining subplans, since ANDing them can no longer change the result. (Note: the fact that indxpath.c orders the subplans by selectivity should make this case more likely to occur.)

ExecReScan doesn't know about my subplans, so I have to do changed-parameter signaling myself.

EXPLAIN identity in core source

case T_BitmapAnd:
			pname = sname = "BitmapAnd";
			break;

Related entries

• EXPLAIN
• Using EXPLAIN
• Parallel plans

Documentation and source

• src/backend/commands/explain.c:1415
• src/backend/executor/execProcnode.c:196
• src/backend/executor/nodeBitmapAnd.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain

Compare versions

PostgreSQL 17 → 18: unchanged.

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

• Bitmap Index ScanBitmapIndexScan
• BitmapOrBitmapOr