本篇详细介绍 PostgreSQL 中 parallel_setup_cost 和 parallel_tuple_cost 两个与并行查询相关的关键成本参数。

概述

这两个参数是 PostgreSQL 查询优化器成本模型的一部分，用于决定是否使用、以及使用多大程度的并行查询。它们不是开关，而是帮助优化器权衡「并行执行带来的性能收益」与「并行执行本身的开销」的砝码。

---

1. parallel_setup_cost

定义

parallel_setup_cost 表示启动并行工作进程（Background Workers）的初始开销成本。

作用

• 优化器在计算并行路径的总成本时，会一次性加上这个值
• 代表了进程创建、通信通道建立、初始状态同步等开销
• 默认值： 100

工作方式

总成本 = 串行执行成本 - (并行减少的成本) + parallel_setup_cost + parallel_tuple_cost

如果 总成本 仍然低于串行执行成本，优化器就会选择并行计划。

调整建议

• 调高（例如设为 200）：表示你认为并行启动开销很大，优化器会更保守地选择并行查询。适用于CPU负载高、进程创建开销大的系统。
• 调低（例如设为 50）：表示你认为并行启动开销很小，优化器会更积极地使用并行查询。适用于CPU空闲、I/O密集型的负载。

---

2. parallel_tuple_cost

定义

parallel_tuple_cost 表示每个元组（tuple）从工作进程传递到主进程的通信开销成本。

作用

• 优化器会根据预估的结果集行数乘以这个值来计算总通信成本
• 代表了进程间数据传输、同步的开销
• 默认值： 0.1

工作方式

总通信成本 = 预估行数 × parallel_tuple_cost

这个成本会加到并行查询的总成本中。

调整建议

• 调高（例如设为 0.2）：表示进程间通信开销很大（如跨NUMA节点），优化器会对返回大量数据的查询避免使用并行。
• 调低（例如设为 0.05）：表示进程间通信效率很高，优化器会对返回大量数据的查询更倾向于使用并行。

---

实际应用示例

-- 查看当前设置
SELECT name, setting, short_desc 
FROM pg_settings 
WHERE name IN ('parallel_setup_cost', 'parallel_tuple_cost');

-- 修改设置（通常在postgresql.conf中，或会话级设置）
ALTER SYSTEM SET parallel_setup_cost = 150;
ALTER SYSTEM SET parallel_tuple_cost = 0.05;

-- 重新加载配置
SELECT pg_reload_conf();

调优场景建议

场景	parallel_setup_cost	parallel_tuple_cost	原因
OLTP负载	调高 (100 → 200)	调高 (0.1 → 0.2)	避免短查询的并行开销
OLAP/报表	调低 (100 → 50)	调低 (0.1 → 0.05)	鼓励大数据量查询并行化
高CPU系统	调高	保持默认	避免过多进程竞争CPU
高I/O系统	调低	调低	利用并行加速I/O操作
大量小查询	调高	调高	避免并行启动 overhead
少量大查询	调低	调低	充分发挥并行优势

注意事项

1. 需要重启/重载：在 postgresql.conf 中修改后需要 pg_reload_conf()
2. 结合其他参数：还需考虑 max_parallel_workers_per_gather、max_worker_processes 等
3. 监控效果：使用 EXPLAIN ANALYZE 对比并行与非并行计划的执行时间
4. 不要盲目调整：基于实际工作负载测试后再做调整

通过合理调整这两个参数，可以显著优化 PostgreSQL 在大数据量查询时的性能表现。