max_parallel_workers是并行总上限，单个查询的并行度由max_parallel_workers_per_gather等参数共同决定，需结合表大小、成本估算和系统负载综合配置以平衡性能与资源。
PostgreSQL 的并行查询能力从 9.6 版本开始引入，允许在扫描、连接和聚合等操作中使用多个工作进程来提升查询性能。决定并行度的核心参数之一是 max_parallel_workers，但它并不是唯一因素。理解它如何影响并行执行，需要结合整个并行策略来看。
max_parallel_workers 是什么？
max_parallel_workers 是一个全局设置，定义了整个 PostgreSQL 实例中可用于并行操作的最大后台进程总数。这些进程不仅用于并行查询，还可能被并行维护操作（如 CREATE INDEX）占用。它限制的是系统层面的资源，而不是单个查询能用多少。
这个值通常在 postgresql.conf 中配置，例如：
max_parallel_workers = 8表示最多允许 8 个并行工作进程在整个集群中运行。
单个查询的并行度由谁决定？
虽然 max_parallel_workers 是总上限，但每个查询实际使用的并行 worker 数量由以下参数逐层控制：
- max_parallel_workers_per_gather：控制单个 GATHER 节点（即发起并行任务的主进程）最多能申请多少 worker。默认可能是 2 或根据 max_parallel_workers 动态计算。
- max_parallel_tablespace 和 max_parallel_maintenance_workers：分别限制表空间和维护操作（如索引创建）使用的并行数，不直接影响普通查询。
- parallel_setup_cost 和 parallel_tuple_cost：优化器用它们估算并行执行的开销。如果成本太高，即使有可用 worker，也可能选择不并行。
- min_parallel_table_scan_size 和 min_parallel_index_scan_size：只有当表或索引大小超过这些阈值时，才考虑并行扫描。
举个例子：即使 max_parallel_workers 设置为 8，如果 max_parallel_workers_per_gather 是 2，那么一个查询最多只能使用 2 个并行 worker。
并行策略是如何工作的？
PostgreSQL 查询优化器在生成执行计划时，会评估是否启用并行。流程大致如下：
- 检查表是否适合并行扫描（如堆表支持，某些外部表或物化视图可能不支持）。
- 判断表大小是否超过 min_parallel_table_scan_size，避免小表浪费资源。
- 计算并行执行的预估成本，包括启动额外进程的开销（parallel_setup_cost）和数据传递成本（parallel_tuple_cost）。
- 检查当前是否有足够的可用 worker（受 max_parallel_workers 和 max_parallel_workers_per_gather 限制）。
- 若综合评估划算，则生成包含 Parallel Seq Scan 或 Parallel Index Scan 的计划，并通过 Gather 节点汇总结果。
可以通过 EXPLAIN 查看是否启用了并行：
EXPLAIN SELECT * FROM large_table WHERE id > 1000;输出中若出现 "Gather" 和 "Workers Launched"，说明并行已启用。
如何合理设置并行参数？
设置并行度需权衡资源利用率与并发查询数量：
- CPU 核心多、大表查询频繁的系统可适当提高 max_parallel_workers，比如设为 CPU 核心数的 50%~75%。
- 若系统同时运行大量查询，不宜让单个查询占用过多 worker，应控制 max_parallel_workers_per_gather（如设为 4）。
- SSD 存储下 I/O 成本低，可调低 parallel_tuple_cost 鼓励更多并行。
- 高并发 OLTP 场景建议降低甚至关闭并行（设为 0），避免进程争抢。
基本上就这些。max_parallel_workers 是并行能力的“总闸门”，但真正决定每个查询跑几个 worker 的，是一整套策略和参数配合的结果。合理配置才能在性能和资源之间取得平衡。
