Hash

说明

构建供哈希连接使用的哈希表。

核心节点标签

T_Hash

结构化 EXPLAIN 节点类型

Hash

输入

哈希连接的内侧子计划

输出

哈希表，不是普通元组流

执行器初始化函数

ExecInitHash

内存机制

hash-batches

EXPLAIN 名称与属性

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

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

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

内存与临时存储

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

此时应开始哈希处理；如果刚到达此处而哈希处理已在进行，则加入其中。哈希处理期间随时可能需要协助增加批次或桶数；如果到达时扩容已在进行，必须立即协助完成，之后才能安全访问下方的批次和桶。

在任何进程尝试加载落盘元组之前，确保这些元组对其他进程可见。

选出一个后端来禁止继续增长。至此批次固定下来。构建批次时已确保日后重新加载时能放入内存预算；或者曾尝试确保这一点，但因检测到极端倾斜而放弃。

Parallel Hash 尝试合并所有工作进程的 hash_mem，以避免分批处理；如果无法做到，则退回每个工作进程各用 hash_mem，并尝试并行处理各批次。

并行执行与运行信息采集

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

此构建的回调：ExecHashEstimate, ExecHashInitializeDSM, ExecHashInitializeWorker, ExecHashRetrieveInstrumentation.

同版本手册说明

这里，规划器选择了哈希连接：先将一个表的行放入内存中的哈希表，再扫描另一个表，并为其中的每一行查找哈希表中的匹配项。注意缩进如何反映计划结构：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)

执行器实现说明

为哈希连接构建哈希表；如果需要多个批次，则进行分区。

不直接返回哈希表，因为它不是 Node 的子类型，会违反 MultiExecProcNode API。父级 Hashjoin 节点应自行从当前节点状态中取出哈希表。虽然不太美观，但 Hashjoin 本来就了解 Hash 的许多内部细节，不值得为此整理。

不感知并行的版本，构建后端私有哈希表，并在需要时创建批次文件。

从 Hash 节点下方的节点获取全部元组，插入哈希表（或临时文件）。

在 spaceUsed 中计入哈希桶占用（会在 EXPLAIN ANALYZE 中报告）。

核心源码中的 EXPLAIN 标识

case T_Hash:
			pname = sname = "Hash";
			break;

相关条目

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

文档与源码

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

版本比较

PostgreSQL 17 → 18: 无变化。

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

相关条目

• Hash JoinHashJoin
• Merge JoinMergeJoin
• Nested LoopNestLoop