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 分布，否则优化就变成调参玄学。
