PostgreSQL 16 的并行 JOIN 需满足数据量、成本估算和执行路径三重条件才启用；EXPLAIN 无 Gather 节点主因是优化器未选择并行路径，常见于小表、volatile 函数、缺失索引或物化 CTE 等硬性限制。
PostgreSQL 16 的并行 JOIN 不是自动生效的魔法，它只在满足数据量、成本估算、执行路径三重条件时才真正启用；盲目调高 max_parallel_workers_per_gather 或把小表 JOIN 塞进函数里，反而会因协调开销拖慢查询。
为什么 EXPLAIN 看不到 Gather 节点？
并行 JOIN 失效最常见的原因是优化器根本没考虑并行路径——不是你没写对，而是它“看不上”。典型现象包括：
-
EXPLAIN ANALYZE输出里只有Hash Join或Merge Join，完全没出现Gather或Gather Merge - 实际扫描行数远低于
min_parallel_table_scan_size默认值（8MB），比如一张只有 200 万行、每行 50 字节的表，物理大小约 100MB，但按块估算后可能未达阈值 - JOIN 条件中用了 volatile 函数（如
now()、random()）或带FOR UPDATE锁，直接禁用并行 - 被 JOIN 的某张表有全表扫描但无可用索引，而另一张表又极小（如配置表），优化器判定串行更省事
哪些 JOIN 类型真能并行？
PostgreSQL 16 支持并行的 JOIN 主要依赖底层扫描和连接算法是否可分片。关键看执行计划中是否出现 Partial Hash Join 或 Partial Merge Join：
-
Hash Join：当内表（inner relation）支持并行顺序扫描，且哈希表能被拆分构建时，才可能生成Partial Hash+Gather结构 -
Merge Join：仅当两张表都已按 JOIN key 排序（如都有对应索引），且排序过程本身可并行（需ORDER BY字段上有索引或提前CREATE INDEX ... INCLUDE）时，才可能触发Partial Merge -
Nested Loop：基本不并行，除非外层驱动表极小且内层被扫描部分极大，此时可能并行化内层扫描，但 JOIN 逻辑本身仍是串行
验证方式很简单：EXPLAIN (ANALYZE, VERBOSE) 中若出现 Gather 节点，且其子节点含 Partial 前缀（如 Partial Hash Join），说明并行已介入。
怎么让 JOIN 查询真正跑出并行效果？
必须手动干预 session 级参数，并确保数据与结构配合。以下操作应在查询前或函数体内用 SET LOCAL 执行（避免污染全局）：
- 设工作进程数：
SET LOCAL max_parallel_workers_per_gather = 4;（别超 CPU 核心数，建议 ≤max_worker_processes / 2） - 调低触发门槛：
SET LOCAL min_parallel_table_scan_size = 4MB;（生产环境慎用低于 4MB 的值） - 压低成本估算：
SET LOCAL parallel_setup_cost = 2;和SET LOCAL parallel_tuple_cost = 0.005; - 保障内存：
SET LOCAL work_mem = '128MB';（总内存 ≈ (1 + workers) ×work_mem，太小会导致磁盘溢出） - 确保 JOIN 字段有索引：哪怕走全表扫描，也建议在 JOIN key 上建索引——这会影响排序/哈希构建阶段是否可并行
注意：SET LOCAL 只对当前事务块或函数体有效；如果在 CREATE OR REPLACE FUNCTION 里调用 JOIN 查询，这些设置仍起作用，但函数内若含 PERFORM 或中间赋值（如 SELECT ... INTO），可能触发 planner 早退出，跳过并行候选路径。
最容易被忽略的结构性限制
即使参数全对、数据够大、索引齐全，并行 JOIN 仍可能失败，因为 PostgreSQL 对「可并行性」有硬性约束：
- JOIN 的任意一侧不能是物化 CTE（
WITH x AS MATERIALIZED (...) SELECT ...），物化动作强制串行 - 不能在子查询中嵌套 JOIN 后再对外层聚合（如
SELECT count(*) FROM (SELECT * FROM t1 JOIN t2 ON ...) s GROUP BY ...），外层 GROUP BY 若不支持并行，整个链路退化 - 分区表 JOIN 时，若分区键与 JOIN key 不一致，分区裁剪失效，导致扫描膨胀，优化器倾向放弃并行
-
work_mem设置不足时，Hash Join的哈希表可能落盘，而磁盘哈希无法并行构建——这是线上最常被漏查的一环
真正有效的并行 JOIN，永远始于对执行计划的逐层确认，而不是堆参数。先用 EXPLAIN (ANALYZE, BUFFERS) 看清哪一步卡住，再决定动哪根参数杠杆。
