并行聚合通过主进程协调多个工作者并行处理数据分片，各自执行局部聚合后由主进程合并结果。其执行需满足表足够大、使用顺序扫描、聚合函数可分割及无阻塞并行元素等条件，并受max_parallel_workers_per_gather等参数控制，通过EXPLAIN可查看Gather与Parallel Seq Scan判断是否启用。
PostgreSQL 中的并行聚合（Parallel Aggregation）是查询执行优化的重要特性，它允许数据库在多核 CPU 环境下利用多个工作进程同时处理聚合操作，从而提升大规模数据统计的性能。理解其执行机制和启用条件，有助于合理设计查询与索引。
并行聚合如何执行
当 PostgreSQL 执行一个包含聚合函数（如 SUM、COUNT、AVG 等）的查询，并且数据量较大时，优化器会评估是否使用并行模式来加速扫描和部分聚合计算。
并行聚合的执行流程大致如下：
- 主进程（Leader Process）启动后，根据表大小、系统资源和参数设置决定是否开启并行执行。
- 创建若干个并行工作者（Parallel Workers），每个工作者扫描表的一个数据块。
- 每个工作者在其负责的数据范围内进行“局部聚合”（Partial Aggregation），例如各自计算一部分的 COUNT 或 SUM。
- 局部结果被发送回主进程，主进程对这些中间结果进行“最终聚合”（Final Aggregation），合并成最终结果。
这种分而治之的方式显著减少了单线程处理的压力，尤其适用于全表扫描类的大数据量聚合查询。
聚合并行模式的启用条件
并非所有聚合查询都能自动使用并行模式。要使 PostgreSQL 启用并行聚合，需满足一系列前提条件：
- 表足够大：只有当顺序扫描的成本较高时，优化器才会考虑并行。小表通常不会触发并行。
- 支持并行扫描的访问方法：目前主要是堆表的顺序扫描支持并行。如果查询走了索引扫描（Index Scan），默认不支持并行。
- 聚合函数是“可分割的”：像 SUM、COUNT 这样的函数可以拆分为部分计算再合并；但某些复杂函数或用户自定义聚合可能无法并行化。
- 查询中没有阻塞并行的元素：例如使用了 FOR UPDATE、存在 volatile 函数、或设置了 parallel_safe = false 的函数。
关键配置参数
PostgreSQL 提供多个 GUC 参数控制并行行为：
- max\_worker\_processes：系统最大并行进程数，影响整体并发能力。
- max\_parallel\_workers\_per\_gather：每个 Gather 节点最多使用的并行工作者数量，例如设为 4，则最多启动 4 个 worker。
- parallel\_setup\_cost 和 parallel\_tuple\_cost：用于评估并行开销，调整它们可影响优化器选择并行的倾向。
- min\_parallel\_table\_scan\_size 和 min\_parallel\_index\_scan\_size：设置表或索引扫描达到多大体积才考虑并行，默认为 4MB 左右。
适当调大 max\_parallel\_workers\_per\_gather 可提升聚合性能，但需结合 CPU 核心数合理设置，避免资源争抢。
查看是否启用并行聚合
使用 EXPLAIN 或 EXPLAIN ANALYZE 可观察执行计划中是否有并行操作：
Gather Workers Planned: 3 -> Partial Aggregate -> Parallel Seq Scan on sales_table Filter: sale_date > '2023-01-01'上述执行计划显示启用了 3 个并行工作者，进行局部扫描和聚合，主进程通过 Gather 收集结果完成最终聚合。
基本上就这些。只要数据量够大、查询结构合适，并且参数配置得当，PostgreSQL 就能自动启用并行聚合来提速。关键是理解它的触发机制和限制条件，避免误以为“应该并行却没并行”。
