Gather Merge

说明

归并并行工作进程以及参与执行的领导进程的有序输出流。

核心节点标签

T_GatherMerge

结构化 EXPLAIN 节点类型

Gather Merge

输入

一个有序并行子计划

输出

按顺序归并的元组

执行器初始化函数

ExecInitGatherMerge

内存机制

unclassified

EXPLAIN 名称与属性

结构化格式使用上述 Node Type。文本格式名称还可能包含操作、策略、连接类型、扫描方向或聚合阶段属性。

此源码记录的文本名称：Gather Merge.

并行感知与并行安全是不同的计划属性。在并行工作进程内运行的节点不一定是并行感知节点。

内存与临时存储

本次抽取不为此节点设定统一的内存上限或落盘策略。请查看同一构建的实现、相关表达式或提供方。

并行执行与运行信息采集

以下源码回调可以协调执行或收集工作进程的测量数据。回调存在不代表该节点普遍支持共享并行扫描或共享状态。

此构建的回调：none extracted from this node implementation.

同版本手册说明

PostgreSQL 通过分两个阶段进行聚合来支持并行聚合。首先，每个参与查询并行部分的进程执行一个聚合步骤，为该进程所见到的每个分组产生一个部分结果。这在计划中体现为一个 Partial Aggregate 节点。然后，部分结果通过 Gather 或 Gather Merge 传送给领导者。最后，领导者会把来自所有工作进程的结果再次聚合，以产生最终结果。这在计划中体现为一个 Finalize Aggregate 节点。

执行器实现说明

nodeGatherMerge.c：在多个工作进程中扫描计划并保持顺序地归并。

从工作进程读取元组时，尽可能一次读取多个可降低上下文切换开销。但一次读取过多会浪费内存而无助于性能。因此除第一个元组外，最多再读取 MAX_TUPLE_STORE 个。

每个工作进程的待处理元组数组，保存已从工作进程读取但尚不能处理的额外元组。此结构还保存 done 标志，表示已知该工作进程不再有元组。（领导进程不使用此结构：不为其保存待处理元组，并用 need_to_scan_locally 标志表示是否完成。）

GatherMerge 不支持检查条件，因为在子节点中检查总是更高效。

领导进程可能直接访问 ExecProcNode 的结果（need_to_scan_locally 为真时），也可能通过元组队列接收工作进程的结果。因此，不能简单假定在此节点内计算表达式时，元组槽类型始终固定。

核心源码中的 EXPLAIN 标识

case T_GatherMerge:
			pname = sname = "Gather Merge";
			break;

相关条目

• EXPLAIN
• 使用 EXPLAIN
• 并行计划
• enable_gathermerge
• max_parallel_workers_per_gather

文档与源码

• src/backend/commands/explain.c:1441
• src/backend/executor/execProcnode.c:360
• src/backend/executor/nodeGatherMerge.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · parallel-plans

版本比较

PostgreSQL 17 → 18: 无变化。

比较已记录的接口与属性，排除来源指纹和构建元数据。某个样本中没有记录，不能据此判断实际引入或移除的版本。

相关条目

• GatherGather