Merge Join

说明

利用归并条件连接有序输入流。

核心节点标签

T_MergeJoin

结构化 EXPLAIN 节点类型

Merge Join

输入

有序的外侧和内侧子计划

输出

按所选连接类型生成的连接元组

执行器初始化函数

ExecInitMergeJoin

内存机制

unclassified

EXPLAIN 名称与属性

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

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

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

内存与临时存储

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

并行执行与运行信息采集

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

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

同版本手册说明

归并连接要求输入数据按连接键排序。在这个例子中，两个输入都通过索引扫描按正确顺序访问行而完成排序；不过也可以采用顺序扫描再排序的方式。（对于需要排序很多行的情况，顺序扫描加排序往往会胜过索引扫描，因为索引扫描需要非顺序磁盘访问。）

观察备选计划的一种方法，是利用 第 19.7.1 节 中描述的启用/禁用标志，强迫规划器忽略它认为最便宜的策略。（这是个粗糙但有用的工具。另见 第 14.3 节 。）例如，如果我们并不确信前一个示例中归并连接真的是最佳连接类型，可以试试：

这表明，规划器认为在这个场景下，哈希连接的代价几乎比归并连接高出 50%。当然，接下来的问题就是它是否判断正确。我们可以像 下文 所述，使用 EXPLAIN ANALYZE 来研究。

如本例所示，查询为 INSERT、UPDATE、DELETE 或 MERGE 命令时，实际应用表变更的工作由顶层 Insert、Update、Delete 或 Merge 计划节点完成。其下的计划节点负责定位旧行和／或计算新数据。因此，上例仍采用前面见过的位图表扫描，其输出传给 Update 节点，由后者存储更新后的行。虽然数据修改节点可能消耗相当多的运行时间（本例中占了绝大部分），但规划器目前并未将这部分工作计入代价估算。这是因为任何正确查询计划需要完成的这部分工作都相同，因此不会影响规划决策。

当 UPDATE 、 DELETE 或 MERGE 命令影响分区表或继承层次时，输出可能像这样：

归并连接的测量结果也可能产生误导。若一侧输入已耗尽，另一侧的下一个键值又大于已耗尽输入的最后一个键值，就不会再有匹配，因此会停止读取另一侧。这样便未读取该子节点的全部行，类似 LIMIT 的情况。另外，外侧（第一个）子节点有重复键值时，内侧（第二个）子节点会回退并重新扫描匹配该键值的行。EXPLAIN ANALYZE 会将内侧重复输出的行计作额外的真实行。因此外侧重复值很多时，内侧计划节点报告的实际行数可能显著超过内侧关系中的实际行数。

本版手册中的示例

示例摘自 PostgreSQL 18.6 手册；本百科未实际执行此示例。

另一种可能的连接方式是归并连接，如下所示：

EXPLAIN SELECT *
FROM tenk1 t1, onek t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;

                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Merge Join  (cost=0.56..233.49 rows=10 width=488)
   Merge Cond: (t1.unique2 = t2.unique2)
   ->  Index Scan using tenk1_unique2 on tenk1 t1  (cost=0.29..643.28 rows=100 width=244)
         Filter: (unique1 < 100)
   ->  Index Scan using onek_unique2 on onek t2  (cost=0.28..166.28 rows=1000 width=244)

执行器实现说明

归并连接对满足 ((= outerKey innerKey) ...) 形式连接条件的内外侧元组执行连接。连接条件列表由查询规划器提供，可以包含多个 (= outerKey innerKey) 条件，以支持复合排序键。

不过，查询执行器需要判断外侧元组是否“大于／小于”内侧元组，以便“同步”两个关系。例如，考虑以下关系：

outer: (0 ^1 1 2 5 5 5 6 6 7) current tuple: 1 inner: (1 ^3 5 5 5 5 6) current tuple: 3

为继续归并连接，执行器需要扫描内外侧关系，直到找到匹配的元组 5。它需要知道当前内侧元组 3“大于”外侧元组 1，因此应先扫描外侧关系以寻找匹配，依此类推。

因此，不直接执行归并连接条件，而是分别求值左右键表达式，再逐列比较（参见 MJCompare）。规划器提供足够的输入排序信息，让执行器确定比较方法。可以使用相应的 B-tree 比较函数，因为 Postgres 的排序语义仅由 B-tree 操作符家族定义。

核心源码中的 EXPLAIN 标识

case T_MergeJoin:
			pname = "Merge";	/* "Join" gets added by jointype switch */
			sname = "Merge Join";
			break;

相关条目

• EXPLAIN
• 使用 EXPLAIN
• 并行计划
• enable_mergejoin

文档与源码

• src/backend/commands/explain.c:1424
• src/backend/executor/execProcnode.c:302
• src/backend/executor/nodeMergejoin.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain

版本比较

PostgreSQL 17 → 18: 无变化。

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

相关条目

• HashHash
• Hash JoinHashJoin
• Nested LoopNestLoop