postgresql 14 默认不并行化子查询，因其被归类为不可并行化节点；优化方法是改写为 join 或 lateral，调优配置并确保统计信息准确。
PostgreSQL 14 默认不会并行化子查询，哪怕外层启用了并行扫描——这是多数人卡住的第一关。
为什么子查询不走并行？
PostgreSQL 的并行查询计划只在「可并行化节点」上触发，而绝大多数子查询（尤其是 IN、EXISTS、标量子查询）被归类为「不能下推并行」的节点。优化器会直接放弃对子查询部分生成并行路径，哪怕子查询本身查的是大表。
-
IN (SELECT ...)子查询默认转成 Hash Semi Join，但若子查询未被物化或无法内联，就无法参与并行 -
EXISTS子查询若含相关变量（correlated），几乎必然串行执行 - 标量子查询（如
SELECT (SELECT COUNT(*) FROM big_table WHERE ...) FROM small_table）每个外层行都重新执行，完全无法并行 - 即使给子查询加了
/*+ Parallel(4) */提示（需pg_hint_plan），PostgreSQL 14 原生也不识别该提示作用于子查询内部
能并行的子查询写法：改写为 JOIN 或 LATERAL
真正可行的加速路径是让子查询“退化”为可并行的连接操作。核心原则：把逻辑从「逐行求值」变成「批量关联」。
- 把
WHERE id IN (SELECT id FROM big_table WHERE ...)改成INNER JOIN (SELECT DISTINCT id FROM big_table WHERE ...) t USING (id)—— 后者中子查询变成FROM子句，优化器更可能对其启用并行顺序扫描 + 并行 Hash - 用
LATERAL替代相关子查询：例如SELECT *, (SELECT MAX(x) FROM log WHERE log.ref_id = t.id) FROM tab t→ 改为SELECT *, l.mx FROM tab t LEFT JOIN LATERAL (SELECT MAX(x) AS mx FROM log WHERE log.ref_id = t.id) l ON true；此时LATERAL子查询虽仍单次执行，但若log表足够大且有合适索引，其内部扫描可并行（需确保log.ref_id上有索引，否则并行无意义） - 避免在子查询中使用
ORDER BY ... LIMIT 1，它会强制 Materialize 节点，阻断并行；改用窗口函数或DISTINCT ON配合索引扫描
关键配置与检查点
即使重写成功，缺几个配置照样白搭。别只盯着 SQL 写法。
- 确认
max_parallel_workers_per_gather> 0（默认是 2），且总 worker 数没被max_worker_processes卡死 -
parallel_setup_cost和parallel_tuple_cost值偏高会导致优化器“觉得不划算”，大表建议调低：比如设为parallel_setup_cost = 100、parallel_tuple_cost = 0.01 - 用
EXPLAIN (ANALYZE, VERBOSE)检查执行计划里是否出现Gather或Gather Merge节点，并确认其子节点（如Parallel Seq Scan）真实存在——注意：如果看到Workers Planned: 2但Workers Launched: 0，说明并行被 runtime 中止（常见于内存不足或锁冲突） - 子查询涉及的表必须有 ANALYZE 过的统计信息，否则优化器无法估算并行收益；对超大表，考虑用
ALTER TABLE ... SET (autovacuum_analyze_scale_factor = 0.01)加密采样
最常被忽略的一点：并行加速只对「计算密集型扫描」有效，如果子查询实际走的是索引点查（Index Scan）或被缓存命中，强行并行反而因调度开销变慢。先看 EXPLAIN 里是不是真在扫全表，再决定要不要动并行配置。
