并行查询跑不快，问题往往出在 parallel_workers 与 CPU 核数不匹配。PostgreSQL 的并行体系由多个参数层层约束，worker 数设置过小会导致多核服务器只用上一两个核心，大表扫描慢得离谱；设置过大又会引发进程争抢、上下文切换开销和内存压力，甚至出现并行比串行更慢的反常情况。本文从参数层级关系讲起，给出可以直接落地的经验公式，并用 EXPLAIN 验证配置效果。
先理清三个层级的并行参数
PostgreSQL 的并行配置是层层嵌套的。最外层是 max_worker_processes，它是整个实例后台进程的总闸门，默认值 8，逻辑复制 worker、扩展插件的辅助进程都从这里扣配额。中间层是 max_parallel_workers，从总闸门里划出一部分专门给并行查询用，默认也是 8。最里层才是单个 Gather 节点下的 max_parallel_workers_per_gather，它决定一条查询一次最多能拉起多少个并行 worker。
很多并行不生效的案例，根源都在于前两层配置过低。比如 32 核服务器上 max_worker_processes 还是默认的 8，即使表级设置 parallel_workers = 16，实际也起不来那么多进程，因为配额在系统层面就被卡死了。基线建议是：max_worker_processes 设为物理核数的 1 到 1.5 倍，max_parallel_workers 设为物理核数本身，给逻辑复制等其他后台任务留出余量。
需要特别强调物理核与逻辑核的区别。超线程带来的逻辑核翻倍并不意味着计算能力翻倍，对并行查询这种计算密集型负载，超线程的提升通常只有 20% 到 30%。经验做法是按物理核数计算并行度，或者对逻辑核数打七折，盲目按逻辑核拉满 worker 只会造成调度抖动。
parallel_workers 是怎么计算出来的
每个查询实际拿到的并行度遵循一条优先级链。如果建表或 ALTER TABLE 时显式指定了 parallel_workers，比如 ALTER TABLE big_table SET (parallel_workers = 4);，优化器直接采用这个值，不再走默认估算。如果没有显式设置，PostgreSQL 会按表大小启发式计算：数据量每翻一倍，规划中的 worker 数加一，从 min_parallel_table_scan_size 对应的 1 个 worker 起步，同时受 max_parallel_workers_per_gather 上限约束。这个上限默认值只有 2，是很多人感觉并行没开起来的最常见原因。
-- 查看当前实例的并行相关配置 SHOW max_worker_processes; SHOW max_parallel_workers; SHOW max_parallel_workers_per_gather; -- 显式为表设置固定的并行 worker 数 ALTER TABLE big_table SET (parallel_workers = 4); -- 恢复为默认的启发式估算 ALTER TABLE big_table RESET (parallel_workers); -- 会话级别放宽单节点并行上限 SET max_parallel_workers_per_gather = 8;
表级显式设置适合两种场景：一是数据分布和查询模式固定的大表，比如数仓中的事实表，手动钉住一个合理值比让优化器估算更稳定；二是分区表场景，若希望每个分区扫描都用固定并行度，可以在父表上统一设置。缺点是表增长后该值不会自动调整，需要定期复查。
与 CPU 核数匹配的经验公式
单条查询的并行度建议控制在物理核数的一半到三分之二之间，绝对不要按物理核数拉满，因为 leader 进程本身也参与元组处理和汇总，加上操作系统调度和其他会话，拉满必然争抢。第一条公式针对低并发的报表分析场景：max_parallel_workers_per_gather = 物理核数 / 2，同时把结果限制在 4 到 8 的范围内。例如 16 物理核的机器，单条大查询用 8 个 worker 是比较稳妥的上限，留出 8 个核给 leader 进程、WAL 写入和系统开销。
第二条公式针对有并发查询的混合负载：单查询并行度 = 物理核数 / (活跃并发查询数 + 1)。假设 16 核机器上预计同时跑 3 条重查询，那么 16 除以 4 等于 4，每个查询配置 4 个 worker，总体不会超载。如果业务并发波动大，宁可把公式算出的值再下调一档，因为并行查询的收益在 IO 或锁等待场景下会大打折扣，超配的坏处远大于欠配。
第三条针对表级 parallel_workers 的估算：表级 worker 数 = min(表大小GB / 2, 物理核数 / 2)。这个公式的含义是数据量每 2GB 配一个 worker，但不超过核数一半的上限。比如 100GB 的事实表在 16 核机器上，100 除以 2 等于 50，超过上限，取 8 即可。数据量低于 2GB 的表干脆不设并行，启动 worker 的开销比节省的时间还多。
-- 16 核机器、低并发报表库的参考配置（postgresql.conf） max_worker_processes = 16 max_parallel_workers = 16 max_parallel_workers_per_gather = 8 -- 16 核机器、3 路并发混合负载的参考配置 max_worker_processes = 16 max_parallel_workers = 12 max_parallel_workers_per_gather = 4
用 EXPLAIN 验证并行度是否合理
配置调完必须用 EXPLAIN ANALYZE 验证。观察执行计划中 Gather 或 Gather Merge 节点上方的 Workers Planned 和 Workers Launched，前者是规划并行度，后者是实际启动的 worker 数。两者不一致说明系统级配额被其他会话占用了，需要检查 pg_stat_activity 里是否有大量并行查询同时运行。
EXPLAIN ANALYZE SELECT region, sum(amount) FROM big_table GROUP BY region; -- 输出示例（节选） -- Finalize GroupAggregate (actual time=8231.512..8235.104 rows=50 loops=1) -- -> Gather Merge (Workers Planned: 4, Workers Launched: 4) -- -> Partial GroupAggregate -- -> Parallel Seq Scan on big_table -- (actual rows=2500000 loops=5)
loops=5 说明这条查询实际用了 4 个 worker 加 1 个 leader 共 5 个进程。对比评估时要做一个简单实验：同一条查询分别在 per_gather 为 4、8、12 三档下跑，记录总耗时和每 worker 的实际处理行数。如果 8 个 worker 和 12 个 worker 的耗时差距在 5% 以内，就选 8，多出来的核留给并发能力比压榨单条查询更有价值。同时关注内存指标，work_mem 是按每个并行进程独立分配的，worker 数翻倍意味着排序哈希类操作的内存占用也翻倍，这也是不能盲目拉高并行度的重要原因。
PostgreSQLparallel_workersCPU核数并行查询修改时间：2026-08-31 03:01:18