BitmapOr

Description

Unions bitmaps produced by its child plans.

Core node tag

T_BitmapOr

Structured EXPLAIN Node Type

BitmapOr

Inputs

Bitmap-producing child plans

Output

Tuple-location bitmap, not a tuple stream

Executor initializer

ExecInitBitmapOr

Memory mechanism

bitmap-lossification

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

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

The node allocates a tuple-location bitmap using a work_mem-derived budget. A bitmap can retain page-level lossy entries instead of every tuple location; heap rechecks then remain necessary.

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.

Executor implementation notes

NOTES BitmapOr 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".

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

We can special-case BitmapIndexScan children to avoid an explicit tbm_union step for each child: just pass down the current result bitmap and let the child OR directly into it.

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

EXPLAIN identity in core source

case T_BitmapOr:
			pname = sname = "BitmapOr";
			break;

Related entries

• EXPLAIN
• Using EXPLAIN
• Parallel plans
• work_mem

Documentation and source

• src/backend/commands/explain.c:1418
• src/backend/executor/execProcnode.c:201
• src/backend/executor/nodeBitmapOr.c
• src/include/nodes/plannodes.h
• src/backend/nodes/tidbitmap.c
• 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
• BitmapAndBitmapAnd