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. 实际调优建议与监控方法

调整参数后，通过执行计划验证效果：

观察输出中是否出现：

• Workers Launched: 4
• Parallel Seq Scan

若未启用并行，检查：

• 是否满足最小扫描页数（min_parallel_table_scan_size）？
• 是否因函数不可并行化（如自定义函数未标为 PARALLEL SAFE）导致降级？
• 成本参数是否过于保守？可尝试调低 parallel_setup_cost 或 parallel_tuple_cost 测试。

基本上就这些。并行调优不是简单调大参数，而是平衡资源、成本模型和实际负载的过程。正确配置能让大表分析类查询显著提速，但盲目开启可能导致系统整体变慢。