postgresql并行查询未启用的主因是parallel_setup_cost默认值1000.0过高，导致规划器放弃并行；需调低至50.0～200.0，并配合parallel_tuple_cost下调及满足硬性条件（如max_parallel_workers_per_gather>0、无for update等）才能生效。
parallel_setup_cost 太高导致并行根本没启用
postgresql 并行查询不是“写了 select 就自动并行”，它得先算一笔账：启动并行的开销（parallel_setup_cost）是否值得。默认值是 1000.0，对中小查询来说太高了—— planner 一看“光 setup 就要 1000”，干脆单线程跑完拉倒。
常见错误现象：EXPLAIN 显示计划里完全没有 Gather 或 Gather Merge 节点，哪怕表有几千万行、CPU 闲着、max_parallel_workers_per_gather 也设了 4。
- 调低到
50.0～200.0是更现实的起点（SSD + 多核机器可往低走） - 别全局改：只在慢查询前加
SET LOCAL parallel_setup_cost = 50.0;测试效果 - 注意：这个值单位是“规划器成本单位”，和
seq_page_cost同量纲，不是毫秒
parallel_tuple_cost 影响并行扫描的“性价比”判断
parallel_tuple_cost 控制的是：从并行 worker 拿回一条元组的代价。默认 0.1，比单进程的 cpu_tuple_cost（默认 0.01）高 10 倍——planner 默认认为跨进程传数据很贵。
使用场景：当你的表宽很窄（比如只有 2–3 个 int 字段），或用 SSD+NVMe，网络/共享内存延迟极低时，这个默认值就太保守了。
- 可尝试降到
0.02～0.05，尤其配合parallel_setup_cost下调后效果更明显 - 别设成
0.0：会导致 planner 过度激进，小结果集也硬上并行，反而因调度开销变慢 - 该参数对索引扫描无效——它只影响顺序扫描（
Seq Scan）和位图堆扫描（Bitmap Heap Scan）的并行决策
为什么调了参数还是不并行？检查这几个硬性条件
即使 parallel_setup_cost 和 parallel_tuple_cost 都调得很激进，并行也可能被拦在门外。这不是参数问题，而是 PostgreSQL 的硬约束。
-
max_parallel_workers_per_gather必须 > 0（默认是 2，但有些云厂商 RDS 默认关成 0） - 查询不能含不支持并行的节点：比如
FOR UPDATE、窗口函数带RANGE、某些 CTE、或自定义聚合函数未标记PARALLEL SAFE - 目标表必须是普通表（不是视图、物化视图、分区表的父表）；且
relpages统计值不能为 0（VACUUM或ANALYZE没跑过会卡住） - 如果用了
LIMIT，planner 可能预判“取前 10 行没必要并行”，此时加OFFSET 0有时能绕过误判（但非常规手段）
生产环境调参的真实节奏
这两个 cost 参数不是“设一次就稳了”的开关。实际负载中，同一条 SQL 在不同数据量、不同并发压力下，最优值可能差一倍。
- 优先在
EXPLAIN (ANALYZE, BUFFERS)确认并行已生效的前提下微调，而不是凭空压低 - 不要在
postgresql.conf全局修改：用ALTER database ... SET或连接级SET更可控 - 最易被忽略的一点：
parallel_setup_cost和parallel_tuple_cost的作用是“让 planner 更愿意选并行”，但最终是否提速，取决于实际 I/O 吞吐、worker 间数据倾斜、以及你的查询是否真能被拆分——比如一个GROUP BY聚合字段基数极低，所有 worker 全往同一个 hash bucket 里塞数据，那并行反而更慢