max_parallel_workers_per_gather控制每个Gather节点的并行工作进程数，影响并行查询性能；其值需结合CPU核心、并发量、I/O和内存综合调优，并通过执行计划验证并行启用情况，避免资源争抢或成本过高导致性能下降。
PostgreSQL 的并行查询能力允许数据库在执行如顺序扫描、聚合、连接等操作时利用多个工作进程来提升性能。而 max_parallel_workers_per_gather（你提到的 "postgresqlworker" 参数可能是指这个）是控制并行度的核心参数之一。理解它的工作机制和相关调优原理，对提升复杂查询性能至关重要。
1. max_parallel_workers_per_gather 作用解析
该参数定义了每个 Gather 节点（即主进程收集并行 worker 结果的地方）最多可以启动多少个并行工作进程。这些 worker 用于执行并行扫描或并行聚合等任务。
例如：
- 设置为
4，表示一个查询最多可使用 4 个并行 worker。 - 若设为
0，则禁用并行查询。
注意：实际使用的 worker 数还受其他系统级参数限制，比如：
- max_parallel_workers：整个实例中允许的最大并行 worker 总数。
- max_worker_processes：系统允许的最大后台进程总数（包含并行、逻辑复制等）。
最终可用的并行 worker 数取这些参数的最小值约束。
2. 并行查询的触发条件
即使设置了较高的并行度参数，并行也不会在所有查询中自动启用。PostgreSQL 基于成本模型决定是否使用并行。关键因素包括：
- 表大小：小表通常不会触发并行，因为启动 worker 的开销大于收益。
-
sequential_scan_cost：通过
random_page_cost和effective_io_concurrent等参数影响优化器对 I/O 成本的估算。 - parallel_setup_cost：启动并行 worker 的固定开销，默认值较小，但真实环境中可能更高（如 CPU 竞争）。
- parallel_tuple_cost：每条传给主进程的元组的通信成本。
如果优化器估算并行执行总成本高于串行执行，就不会选择并行计划。
3. 如何合理设置并行参数
调优应结合硬件资源与负载特征进行：
-
CPU 核心数：建议将
max_parallel_workers_per_gather设置为 CPU 核心数的 50%~75%，避免过度竞争。例如 16 核机器可设为 4~8。 - 并发查询数：高并发场景下，单个查询占用过多 worker 会导致资源争抢。可通过降低 per-gather 值，提高整体吞吐。
- I/O 能力：SSD 环境更能发挥并行扫描优势，可适当提高并行度。
-
内存：并行 worker 共享
work_mem，大量并行查询可能耗尽内存，需监控。
4. 实际调优建议与监控方法
调整参数后，通过执行计划验证效果：
EXPLAIN (ANALYZE, VERBOSE) SELECT COUNT(*) FROM large_table;观察输出中是否出现：
Workers Launched: 4Parallel Seq Scan
若未启用并行，检查：
- 是否满足最小扫描页数（
min_parallel_table_scan_size）？ - 是否因函数不可并行化（如自定义函数未标为
PARALLEL SAFE）导致降级？ - 成本参数是否过于保守？可尝试调低
parallel_setup_cost或parallel_tuple_cost测试。
基本上就这些。并行调优不是简单调大参数，而是平衡资源、成本模型和实际负载的过程。正确配置能让大表分析类查询显著提速，但盲目开启可能导致系统整体变慢。
