Hash Join

说明

读取外侧输入，同时探测由内侧输入构建的哈希表。

核心节点标签

T_HashJoin

结构化 EXPLAIN 节点类型

Hash Join

输入

外侧子计划与内侧 Hash 计划

输出

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

执行器初始化函数

ExecInitHashJoin

内存机制

hash-batches

EXPLAIN 名称与属性

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

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

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

内存与临时存储

哈希连接可将工作划分为由临时文件承载的批次。这描述的是哈希连接的分批处理，不是聚合或 Memoize 节点的落盘策略。

哈希连接内侧的元组无法全部放入内存时，可以分多个批次执行哈希连接。

如果内侧关系的统计信息准确，规划器会选择多批次策略并估计批次数量。

查询执行器测量哈希表的实际大小，并在哈希表过大时增加批次数。

批次数始终是 2 的幂，因此每次增加都会翻倍。

并行执行与运行信息采集

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

此构建的回调：ExecHashJoinEstimate, ExecHashJoinInitializeDSM, ExecHashJoinInitializeWorker, ExecHashJoinReInitializeDSM.

同版本手册说明

这里，规划器选择了哈希连接：先将一个表的行放入内存中的哈希表，再扫描另一个表，并为其中的每一行查找哈希表中的匹配项。注意缩进如何反映计划结构：tenk1 上的位图扫描是 Hash 节点的输入，Hash 节点据此构建哈希表，再将其交给 Hash Join 节点。后者从外侧子计划读取行，并为每一行搜索哈希表。

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

这里，子计划只执行一次，其输出被装入内存中的 hash 表，随后由外层的 ANY 操作符来探测这个 hash 表。这要求子 SELECT 不能引用外层查询的任何变量，并且 ANY 比较所用的操作符必须适合进行 hash 运算。

在某些情况下，EXPLAIN ANALYZE 除了计划节点的执行时间和行数之外，还会显示额外的执行统计信息。例如，Sort 和 Hash 节点会提供更多信息：

Sort 节点显示排序方法（尤其是内存排序还是磁盘排序）及所需内存或磁盘空间。Hash 节点显示哈希桶数、批次数及哈希表内存使用峰值。（批次数超过一时也会使用磁盘空间，但此处不显示。）

与非并行计划一样，驱动表可以通过嵌套循环、哈希连接或归并连接与一个或多个其他表连接。连接的内侧可以是规划器支持的任何类型的非并行计划，只要它能够安全地在并行工作进程中运行。根据连接类型，内侧也可以是并行计划。

本版手册中的示例

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

稍微改变查询的选择率，就可能得到截然不同的连接计划：

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

                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Hash Join  (cost=226.23..709.73 rows=100 width=488)
   Hash Cond: (t2.unique2 = t1.unique2)
   ->  Seq Scan on tenk2 t2  (cost=0.00..445.00 rows=10000 width=244)
   ->  Hash  (cost=224.98..224.98 rows=100 width=244)
         ->  Bitmap Heap Scan on tenk1 t1  (cost=5.06..224.98 rows=100 width=244)
               Recheck Cond: (unique1 < 100)
               ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
                     Index Cond: (unique1 < 100)

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

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

SET enable_mergejoin = off;

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

                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Hash Join  (cost=226.23..344.08 rows=10 width=488)
   Hash Cond: (t2.unique2 = t1.unique2)
   ->  Seq Scan on onek t2  (cost=0.00..114.00 rows=1000 width=244)
   ->  Hash  (cost=224.98..224.98 rows=100 width=244)
         ->  Bitmap Heap Scan on tenk1 t1  (cost=5.06..224.98 rows=100 width=244)
               Recheck Cond: (unique1 < 100)
               ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
                     Index Cond: (unique1 < 100)

执行器实现说明

此实现基于下页简要介绍的“混合哈希连接”算法。

"An Adaptive Hash Join Algorithm for Multiuser Environments" Hansjörg Zeller; Jim Gray (1990). Proceedings of the 16th VLDB conference. Brisbane: 186–197.

哈希连接内侧的元组无法全部放入内存时，可以分多个批次执行哈希连接。

如果内侧关系的统计信息准确，规划器会选择多批次策略并估计批次数量。

查询执行器测量哈希表的实际大小，并在哈希表过大时增加批次数。

核心源码中的 EXPLAIN 标识

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

相关条目

• EXPLAIN
• 使用 EXPLAIN
• 并行计划
• enable_hashjoin
• work_mem

文档与源码

• src/backend/commands/explain.c:1428
• src/backend/executor/execProcnode.c:307
• src/backend/executor/nodeHashjoin.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · parallel-plans

版本比较

PostgreSQL 17 → 18: 无变化。

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

相关条目

• HashHash
• Merge JoinMergeJoin
• Nested LoopNestLoop