PostgreSQL 16 并行 HASH JOIN 需同时满足三条件：优化器选中并行计划、至少一个worker可用、驱动表扫描量≥min_parallel_table_scan_size（默认8MB）；仅当EXPLAIN (ANALYZE, VERBOSE)中出现Parallel Hash节点且Workers Launched≥1时才真正生效。
PostgreSQL 16 中并行 HASH JOIN 的触发条件
并行 HASH JOIN 不是设了 max_parallel_workers_per_gather 就自动出现的。它必须同时满足三个硬性条件：优化器选中并行计划、至少有一个工作进程可用、且 JOIN 的一侧（通常是驱动表）足够大——默认要求扫描数据量 ≥ min_parallel_table_scan_size（8MB）。如果驱动表只有几百行，哪怕开了所有参数，也只会走串行 Hash Join。
常见错误现象：EXPLAIN 输出里没有 Workers Launched: N，也没有 Parallel Hash 字样，只看到普通 Hash Join 节点——这不是配置漏了，而是表太小或被广播的一侧超出了内存限制。
- 小表（被广播侧）大小不能超过
work_mem × max_parallel_workers_per_gather，否则降级为串行 - 含
volatile函数（如now()）、FOR UPDATE、窗口函数的查询会直接禁用并行 - JOIN 条件字段类型不一致（如左表
int4，右表int8）会导致隐式转换，无法利用索引，也可能抑制并行选择
如何验证并行 HASH JOIN 是否真正启用
别只看有没有 Gather 节点——那是并行扫描或聚合的标志，和 JOIN 无关。要确认并行 HASH JOIN 生效，必须在 EXPLAIN (ANALYZE, VERBOSE) 输出中找到这两个关键特征：
-
Parallel Hash节点（出现在 JOIN 上方或内部） -
Workers Launched: N（N ≥ 1），且其子节点包含Hash或Seq Scan等实际执行节点
如果只看到 Hash Join + Gather，说明只是外层聚合或扫描并行了，JOIN 本身仍是串行的。
调参让并行 HASH JOIN 跑起来的关键操作
默认配置下，并行 HASH JOIN 几乎不会触发。需要 session 级临时调整几个参数：
- 设
SET max_parallel_workers_per_gather = 4（建议 ≤ CPU 核心数，别超max_worker_processes） - 压低门槛：
SET min_parallel_table_scan_size = 1MB（测试可用；生产环境按驱动表真实大小微调） - 降低开销预估：
SET parallel_setup_cost = 2和SET parallel_tuple_cost = 0.01 - 确保
work_mem足够：SET work_mem = '256MB'（小表广播失败常因这个太小）
注意：max_parallel_workers_per_gather 控制单个 Gather 节点下的 worker 数，不影响多个查询并发运行；但设太高（比如 16）会在高负载时挤占其他查询资源。
为什么有时并行 HASH JOIN 比串行还慢
并行不是万能加速器。当以下情况发生时，并行 HASH JOIN 可能比串行更耗时：
- 驱动表虽大，但被广播的一侧（build table）过大，导致每个 worker 都要加载一份全量副本，内存带宽打满
-
work_mem不足，worker 进程被迫做磁盘哈希（Disk-based Hash），I/O 成瓶颈 - JOIN 后结果集极大，合并阶段（
Gather Merge）成为新热点，反而拖慢整体 - 数据倾斜严重：某些 key 对应上百万行，单个 worker 卡死，其余 idle
最容易被忽略的是：并行 HASH JOIN 的收益高度依赖驱动表与构建表的相对大小关系——它只对“大表驱动小表”且小表可完整广播的场景最友好；两边都大时，优化器可能主动退回到串行 Merge Join 或更慢的 Nested Loop。
