SQL PostgreSQL 的 parallel query 的 worker 分配与成本阈值调优

postgresql并行查询需协同设置parallel_setup_cost（默认1000，宽表扫描可降至500～800）和parallel_tuple_cost（默认0.1，nvme可试0.02～0.05），避免小查询滥用worker；需结合max_parallel_workers_per_gather、表大小（relpages≥1000）、事务隔离级别及函数稳定性综合判断是否真正启用并行；验证必须用explain (analyze)，关注workers launched≥1及worker子节点实际耗时与缓冲命中；parallel_leader_participation控制leader是否参与扫描，默认on，oltp混合场景建议set local设为off。

parallel_setup_cost 和 parallel_tuple_cost 怎么设才不白配

PostgreSQL 的并行查询不会自动“多核全开”，它靠两个成本阈值决定是否启动 worker：一个算“启动开销”，一个算“每条元组传输代价”。设太高，query 直接放弃并行；设太低，小查询硬拉 worker，反拖慢响应。

典型错误是把 parallel_setup_cost 调成 0 —— 看似“全力并行”，实则让 planner 对简单 select count(*) FROM small_table 也启 4 个 worker，CPU 上下文切换+IPC 开销压过收益。

• parallel_setup_cost 默认 1000，适合中等 OLAP 场景；若大量执行宽表扫描（如 50+ 列、GB 级中间结果），可小幅下调至 500～800
• parallel_tuple_cost 默认 0.1，对 SSD 集群偏保守；NVMe 或本地盘可试 0.02～0.05，但注意：该值越低，并行越激进，worker 数易超 max_parallel_workers_per_gather
• 别单独调一个——这两个值必须协同看。比如你把 parallel_tuple_cost 降到 0.03，却没动 parallel_setup_cost，可能触发一堆“小 scan + 大传输”的低效并行

为什么 EXPLAIN 显示 Parallel Seq Scan 却没用上 worker

常见假象：EXPLAIN 输出里有 Parallel Seq Scan，但 EXPLAIN (ANALYZE) 里 Workers Launched: 0。根本原因不是配置没生效，而是 runtime 检查失败。

关键检查点在执行前一刻：planner 生成计划时认为可以并行，但 executor 启动时发现资源被占、表太小、或被显式禁用。

• 检查 max_parallel_workers_per_gather 是否为 0（默认是 2）；设成 0 会直接跳过所有并行分支
• 确认表大小：若 pg_class.relpages （约 8MB），即使 cost 满足，PG 也可能跳过并行——这是硬编码的底线，不可绕过
• 留意事务隔离级别：REPEATABLE READ 或 SERIALIZABLE 下，某些并行操作（如带 subplan 的 Gather）会被静默降级
• 函数内联问题：如果查询含自定义函数且标记为 volatile，PG 会拒绝并行（怕 side effect 不一致）

如何验证实际用了几个 worker 而不是只信 EXPLAIN

EXPLAIN 是预测，EXPLAIN (ANALYZE, BUFFERS) 才是真相。但即使这样，你也得盯住具体字段，否则容易误判。

重点不是看有没有 “Workers Launched”，而是看 “Worker 0”、“Worker 1” 这些子节点是否真跑了、耗时多少、是否空转。

• 执行 EXPLAIN (ANALYZE, BUFFERS) SELECT ... 后，搜索 Workers Launched: 行，数字必须 ≥1 才算启用
• 往下找 Worker 0 节点，看它的 Actual Total Time —— 如果比主进程还长，说明 worker 分配不均或数据倾斜
• 若看到 Worker 0 有 Buffers: shared hit=xxx，但 Worker 1 全是 read=0，大概率是 partition prune 失败或 hash 分布不均
• 注意：Workers Launched: 2 不代表同时跑满 2 个；若 query 很快结束，可能第二个 worker 根本没拿到任务就退出了

parallel_leader_participation 关键但常被忽略

这个参数控制 leader 进程（即发起查询的 backend）是否参与实际扫描。默认 on，意味着 leader 和 worker 一起干活；设为 off，则 leader 只负责 gather 结果，不扫数据。

它不改变并行度上限，但直接影响 CPU 利用率和响应毛刺。尤其在高并发 OLTP+轻量 OLAP 混合场景，容易踩坑。

• 设为 off 适合短平快分析查询（如 dashboard 实时指标），避免 leader 被绑死在 I/O 上，影响其他连接响应
• 设为 on 更适合大吞吐批处理（如 etl 中间表构建），能更好压满 CPU，但要注意：leader 参与扫描后，work_mem 是 per-worker 计，leader 的那份也会占用，可能触发 spill
• 该参数不能 ALTER SYSTEM 全局设死——不同业务类型冲突太大；建议在 query 前加 SET LOCAL parallel_leader_participation = off;

并行不是开得越多越好，worker 数量、cost 阈值、leader 是否参战，三者咬合紧密。稍微动一个，就得重看整个执行路径里的 time/buffer 分布，否则优化就变成调参玄学。