跳转到主要内容

parallel_setup_cost

parallel_setup_cost:设置规划器启动并行工作进程的成本估计。实测在档范围为 PG9.6–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 1000,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器启动并行工作进程的成本估计。

身份

类型 , real
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 01.79769e+308
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Cost Constants
上游分类
最后 boot 值 , 1000
1000

生命周期

Fact
首次观测 PG9.6
在档版本 PG9.6–19 Beta 3
移除版本
引入提交 3bd909b22093 — Add a Gather executor node.
提交日期 2015-09-30
Discussion

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.6–19 Beta 3 1000 1000

机制详解

parallel_setup_cost 用于刻画为计划启动并行 worker 的固定开销。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

规划器成本单位是任意尺度,只有比例有意义。把所有成本常量同比例缩放不会改变路径排序;只改一项则会改变 I/O、行处理、操作符与并行开销之间的权衡。

生成计划时才会读取该值。统计信息、行数估计、缓存假设、tablespace 覆盖以及可用计划方法,都可能比小幅调整这个常量影响更大。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

Advice。 以下建议是工作负载起点,必须用真实测量验证。

场景 建议
OLTP 只应依据代表性负载校准 parallel_setup_cost,不能依据单个计划。先修复陈旧统计,并用 EXPLAIN (ANALYZE, BUFFERS) 比较估算与实际;能按角色或 tablespace 限定时不要全局修改。
OLAP 分析负载可能需要不同的 CPU 与 I/O 权衡,但应把 parallel_setup_cost 与相关成本模型一起调整,并验证完整的扫描、连接与聚合组合。
小规格 除非反复证据表明存在系统性建模偏差,否则保留上游值。小系统上并发与缓存驻留通常比细调 parallel_setup_cost 更重要。

Pigsty 取值

以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具,并按 PG19 Beta 3 渲染当前 Pigsty 模板;这不表示 Pigsty 当前支持该历史或测试版本。

模板 有效值 与上游 boot 比较 源表达式
OLTP 2000 不同于 boot 值 2000
OLAP 未修改
CRIT 2000 不同于 boot 值 2000
TINY 未修改
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.6–19 Beta 3 = 2000 (dcs);OLAP: PG9.6–19 Beta 3 未修改;CRIT: PG9.6–19 Beta 3 = 2000 (dcs);TINY: PG9.6–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):OLTP/crit 把启动估算翻倍,意在不完全禁用的前提下降低并行计划倾向;OLAP 与 tiny 保留上游行为。

常见坑

  • 把数值解释为实际耗时或硬资源上限。
  • 为修复单条查询而调整,导致更广泛负载回归。
  • 在修正统计信息与基数估计之前先改成本常量。
  • 忘记只有各成本项的相对值会影响路径选择。

parallel_tuple_cost · max_parallel_workers_per_gather · min_parallel_table_scan_size · max_parallel_workers

参考资料