Gather

Description

Combines tuples from parallel workers and any participating leader execution.

Core node tag

T_Gather

Structured EXPLAIN Node Type

Gather

Inputs

One parallel child plan

Output

Combined tuples without a merge-order guarantee

Executor initializer

ExecInitGather

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

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

PostgreSQL supports parallel aggregation by aggregating in two stages. First, each process participating in the parallel portion of the query performs an aggregation step, producing a partial result for each group of which that process is aware. This is reflected in the plan as a Partial Aggregate node. Second, the partial results are transferred to the leader via Gather or Gather Merge . Finally, the leader re-aggregates the results across all workers in order to produce the final result. This is reflected in the plan as a Finalize Aggregate node.

Executor implementation notes

nodeGather.c Support routines for scanning a plan via multiple workers.

A Gather executor launches parallel workers to run multiple copies of a plan. It can also run the plan itself, if the workers are not available or have not started up yet. It then merges all of the results it produces and the results from the workers into a single output stream. Therefore, it will normally be used with a plan where running multiple copies of the same plan does not produce duplicate output, such as parallel-aware SeqScan.

Alternatively, a Gather node can be configured to use just one worker and the single-copy flag can be set. In this case, the Gather node will run the plan in one worker and will not execute the plan itself. In this case, it simply returns whatever tuples were returned by the worker. If a worker cannot be obtained, then it will run the plan itself and return the results. Therefore, a plan used with a single-copy Gather node need not be parallel-aware.

Leader may access ExecProcNode result directly (if need_to_scan_locally), or from workers via tuple queue. So we can't trivially rely on the slot type being fixed for expressions evaluated within this node.

Without projections result slot type is not trivially known, see comment above.

EXPLAIN identity in core source

case T_Gather:
			pname = sname = "Gather";
			break;

Related entries

• EXPLAIN
• Using EXPLAIN
• Parallel plans
• max_parallel_workers_per_gather
• parallel_leader_participation

Documentation and source

• src/backend/commands/explain.c:1438
• src/backend/executor/execProcnode.c:355
• src/backend/executor/nodeGather.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · parallel-plans

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

• Gather MergeGatherMerge