postgresql 16并行group by需同时满足三条件：计划中出现gather节点且子节点为hashaggregate、group by列有索引支持、优化器估算分组后行数远小于输入行数。
PostgreSQL 16 默认不会为 GROUP BY 自动启用并行查询，除非满足严格条件——不是加了 max_parallel_workers_per_gather 就能并行，更不是数据量大就自动并行。
GROUP BY 并行执行的三个硬性前提
PostgreSQL 16 的并行 GROUP BY（即并行哈希聚合）需同时满足：
- 查询计划中必须出现
Gather节点，且其子节点是HashAggregate（不是GroupAggregate）； - GROUP BY 列必须有可用索引支持排序或哈希分发（无索引时通常退化为单线程）；
- 优化器估算的“分组后行数”远小于输入行数（否则认为并行收益低，直接放弃）。
常见误区：给大表建了索引，但 EXPLAIN 里仍是 GroupAggregate + Seq Scan —— 这说明优化器没选并行，不是配置没生效，而是它根本没考虑。
关键参数组合与实操建议
仅调 max_parallel_workers_per_gather 不够，必须协同调整成本参数才能“说服”优化器走并行哈希聚合路径：
- 降低
parallel_tuple_cost：云环境推荐设为0.05（本地 SSD）或0.12（云存储），避免默认值0.1在高基数分组时过早放弃并行； - 适当提高
min_parallel_table_scan_size：对超大表（如 >10GB），可设为'512MB'，防止小扫描被误判为不值得并行； -
force_parallel_mode = on仅用于调试，生产禁用——它会强制并行但可能引发 worker 争抢或内存溢出。
验证是否真正并行：运行 EXPLAIN (ANALYZE, BUFFERS)，重点看是否有 Workers Launched: N 且 HashAggregate 出现在 Gather 下方。
索引设计直接影响并行能否触发
并行哈希聚合不依赖索引排序，但索引能显著提升“分组前过滤”效率，从而让输入行数下降到优化器愿意并行的阈值内：
- 联合索引顺序必须是：分组列 + WHERE 条件列 + 聚合列（如
INDEX ON sales (status, created_at, amount)）； - 避免在 GROUP BY 中使用函数（如
GROUP BY DATE(created_at)），这会让索引失效，优化器大概率跳过并行； - 若分组列值分布极不均匀（如 95% 是
'pending'），考虑用部分索引（WHERE status = 'pending'）或改用整型编码，否则哈希分区倾斜会导致 worker 负载不均。
没有覆盖索引支撑的 WHERE + GROUP BY 组合，即使数据量再大，PostgreSQL 16 也倾向单线程全扫后哈希——因为并行传输和合并的开销已超过收益。
容易被忽略的并发陷阱
并行 GROUP BY 的真实瓶颈常不在 CPU，而在内存和锁竞争：
- 每个 worker 进程都会申请独立的
work_mem，若设为64MB且启动 4 个 worker，单查询最多消耗 256MB 内存——超出shared_buffers或系统限制会触发落盘，性能断崖式下跌； - 云数据库（如 RDS、GaussDB）常限制
max_parallel_workers_per_gather上限（如 AWS RDS 默认为 2），需确认实例规格是否允许调高； - 当多个并行 GROUP BY 查询同时执行，
max_worker_processes和max_parallel_workers可能成为全局瓶颈，此时部分查询会降级为串行，且无明确报错提示。
最隐蔽的问题是：你看到 Workers Launched: 2，但 Execution Time 比串行还长——八成是 work_mem 不足导致哈希表频繁写磁盘，而不是并行本身有问题。
