由 John Doe 十月 22, 2025
你想知道 PostgreSQL 中的查询并行能力是否得到充分发挥吗？
特性提交日志
为 pg_stat_database 视图添加两个并行工作进程活动相关属性。
在 pg_stat_database 中新增两个属性：
- parallel_workers_to_launch：统计计划启动的并行工作进程总数。
- parallel_workers_launched：统计实际启动的并行工作进程总数。
这两个字段的比值可给出提示：在启动并行工作进程时是否存在插槽不足的情况；即便实例未部署 pg_stat_statements 插件（如提交 cf54a2c00254 所示场景），该比值也具有参考价值。
此提交依赖于此前的提交 de3a2ea3b264，之前的提交已在执行状态 EState 中添加了两个字段，当执行Gather（聚集）或GatherMerge（聚集合并）节点时，这两个字段会自动递增。
讨论：https://postgr.es/m/783bc7f7-659a-42fa-99dd-ee0565644e25@dalibo.com
示例
在该特性推出前，PostgreSQL 对并行查询的监控存在明显局限：
- 缺乏全局统计维度：仅能通过
pg_stat_activity查看当前运行查询的并行状态，或依赖 pg_stat_statements 统计单条 SQL 的并行情况，无法获取整个数据库的并行工作进程 “计划启动” 和 “实际启动” 的汇总数据。 - 资源不足排查困难：当并行工作进程因 “插槽不足”（如
max_parallel_workers_per_gather配置过低）无法正常启动时，没有量化指标支撑判断，只能通过查询执行时间变长间接推测，效率低下。 - 无插件场景监控缺失：若实例未部署 pg_stat_statements（部分轻量环境为减少开销会禁用），则完全无法追溯并行工作进程的启动历史，排查问题时陷入 “黑盒”。
此次新增的两个字段，通过数据库级别的汇总统计，直接解决了上述痛点，尤其适用于无插件部署、多数据库并行负载监控场景。
要排查并行工作进程启动失败，判断工作进程资源是否充足，可以执行下面的 SQL 查询：
-- 查看order_db的并行工作进程统计
SELECT
parallel_workers_to_launch AS 计划启动数,
parallel_workers_launched AS 实际启动数,
-- 计算启动成功率，低于90%需警惕资源不足
ROUND(
(parallel_workers_launched::NUMERIC / NULLIF(parallel_workers_to_launch, 0)) * 100,
2
) AS 启动成功率(%)
FROM pg_stat_database
WHERE datname = 'order_db';
-- 若启动成功率低（如80%），检查并行插槽配置
SHOW max_parallel_workers_per_gather; -- 查看单查询最大并行工作者数
SHOW max_parallel_workers; -- 查看实例全局最大并行工作者数
若启动成功率(%)低于 90%，大概率是max_parallel_workers_per_gather配置不足，无法满足计划的并行需求。
优化建议：临时调大配置（如SET max_parallel_workers_per_gather = 8;），或者在postgresql.conf中调整，避免 PostgreSQL 并行资源瓶颈。
非常不错的改进，感谢社区的所有相关人员。
参考
提交日志：https://git.postgresql.org/pg/commitdiff/e7a9496de90657e2161f68b3a5a9b2d9b0b7bb07