↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

百科 / 执行计划节点 / 连接

Hash Join

HashJoin

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

当前查看 PostgreSQL 18.6。

说明

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

核心节点标签
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 标签

文本格式标签结构化节点标识
HashHash Join

相关条目

文档与源码

来源构建
版本
18.6
构建
PostgreSQL 18.6 source archive
来源指纹
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

版本比较

PostgreSQL 10 → 11: 属性变化。

以下差异保留原始字段名与英文源描述。

--- PostgreSQL 10
+++ PostgreSQL 11
@@ -2,7 +2,12 @@
   "initializer": "ExecInitHashJoin",
   "memory_mechanism": "hash-batches",
   "node_tag": "T_HashJoin",
-  "parallel_callbacks": [],
+  "parallel_callbacks": [
+    "ExecHashJoinEstimate",
+    "ExecHashJoinInitializeDSM",
+    "ExecHashJoinInitializeWorker",
+    "ExecHashJoinReInitializeDSM"
+  ],
   "partial_modes": [],
   "strategies": [],
   "text_names": [

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

相关条目

导出 JSON · 返回执行计划节点 · 收录范围为 PostgreSQL 10 至 20;最早采样版本不一定是实际引入版本。