跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

查询调优

Query Tuning 分类下的 55 个 PostgreSQL 核心配置参数档案。

条目 URL 保持扁平;本分类仅用于侧栏与浏览组织。

1 - constraint_exclusion

constraint_exclusion:允许规划器利用约束排除不可能匹配的表。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 partition,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器利用约束排除不可能匹配的表。

身份

类型 , enum
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 , partition, on, off
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , partition
partition

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

constraint_exclusion 允许规划器把查询谓词与 CHECK 约束比较,并排除约束可证明不可能匹配的关系。partition 只对传统继承子表和 UNION ALL 分支执行该工作;它与声明式分区裁剪不同。

证明发生在规划阶段,因此更广泛地开启会增加规划工作,即使最终没有关系可排除。它依赖规划器可见且与查询条件逻辑矛盾的约束。

对声明式分区表,enable_partition_pruning 才是主要开关。constraint_exclusion 仍适用于继承式分区以及精心构造、由约束支撑的 UNION ALL 视图。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 constraint_exclusion 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,constraint_exclusion 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 constraint_exclusion 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 constraint_exclusion 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

enable_partition_pruning · from_collapse_limit · join_collapse_limit · default_statistics_target

参考资料

2 - cpu_index_tuple_cost

cpu_index_tuple_cost:设置规划器处理每个索引条目的成本估计。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0.005,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器处理每个索引条目的成本估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

cpu_index_tuple_cost 用于刻画索引扫描处理一个索引条目的 CPU 工作量。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

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

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

调优建议

提示

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

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

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

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

cpu_tuple_cost · cpu_operator_cost · random_page_cost · seq_page_cost · enable_indexscan

参考资料

3 - cpu_operator_cost

cpu_operator_cost:设置规划器执行每个操作符或函数调用的成本估计。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0.0025,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器执行每个操作符或函数调用的成本估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

cpu_operator_cost 用于刻画每次操作符或函数调用的 CPU 工作量。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

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

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

调优建议

提示

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

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

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

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

cpu_tuple_cost · cpu_index_tuple_cost · jit_above_cost · seq_page_cost

参考资料

4 - cpu_tuple_cost

cpu_tuple_cost:设置规划器处理每个元组(行)的成本估计。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0.01,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器处理每个元组(行)的成本估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

cpu_tuple_cost 用于刻画处理一行的 CPU 工作量。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

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

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

调优建议

提示

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

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

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

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

cpu_index_tuple_cost · cpu_operator_cost · seq_page_cost · random_page_cost · enable_seqscan

参考资料

5 - cursor_tuple_fraction

cursor_tuple_fraction:设置规划器对游标实际取回行比例的估计。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0.1,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器对游标实际取回行比例的估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

cursor_tuple_fraction 告诉规划器预计会取回游标结果的多大比例。比例越小越重视启动成本;1.0 则像会消费全部结果的普通查询一样规划。

该估计可通过偏好更快的首行来改变连接顺序与访问路径,即使总执行时间更慢。它不会在达到该比例后停止 FETCH,也不是行数限制。

该值在规划游标时读取。应用行为至关重要:分页、提前退出与完整导出使用游标时,合适比例完全不同。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 cursor_tuple_fraction 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,cursor_tuple_fraction 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 cursor_tuple_fraction 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 cursor_tuple_fraction 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

plan_cache_mode · random_page_cost · enable_nestloop · enable_indexscan

参考资料

6 - default_statistics_target

为没有单独目标值的列设置 ANALYZE 默认统计细节级别。更多细节可能改善基数估算,但会增加统计收集时间和系统目录空间。
说明

Fact — 官方简述译文:设置未单独指定目标值的列所使用的默认统计目标。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 110000
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , 100
100

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

该目标限制列的最常见值列表条目数和直方图桶数。规划器用这些统计估算行数,进而选择访问路径、连接顺序与连接算法。

ANALYZE 对大表采用抽样而不是读取全部行。抽样规模由本次分析列中的最大统计目标驱动,因此提高目标会大致按比例增加分析时间和空间。

ALTER TABLE … ALTER COLUMN … SET STATISTICS 可按列覆盖全局默认值。多列相关性是另一类问题,通常应使用 CREATE STATISTICS,而不是仅提高本参数。

调优建议

提示

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

场景 建议
OLTP 保持适中的全局目标,只对确实产生行数误估的倾斜列提高;重新运行 ANALYZE,并比较调整前后的估算行数与实际行数。
OLAP 较高基线有助于复杂过滤和连接,但相关谓词应使用扩展统计;批量装载后还要为增加的 ANALYZE 时间留预算。
小规格 适度提高全局值通常成本不高,但按列调优更精确;从不参与过滤、分组或排序的列不需要深直方图。

Pigsty 取值

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

模板 有效值 与上游 boot 比较 源表达式
OLTP 400 不同于 boot 值 400
OLAP 1000 不同于 boot 值 1000
CRIT 400 不同于 boot 值 400
TINY 200 不同于 boot 值 200
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 = 400 (dcs);OLAP: PG9.0–19 Beta 3 = 1000 (dcs);CRIT: PG9.0–19 Beta 3 = 400 (dcs);TINY: PG9.0–19 Beta 3 = 200 (dcs)。 建议(待人工复核)——编辑推断(待维护者复核):各模板以更多 ANALYZE 成本换取更好的估算,其中 OLAP 最重视计划质量,TINY 则限制收集开销。

常见坑

  • 修改参数不会刷新已有统计,之后必须运行 ANALYZE。
  • 提高单列目标本身无法描述跨列相关性。
  • 过高的全局值会让不重要列也承担额外 ANALYZE 工作。
  • 分区子表变化不会触发父表分析,父表可能需要手工 ANALYZE。
  • 抽样仍是近似过程,可能出现估算误差与计划波动。

autovacuum_analyze_scale_factor · autovacuum_analyze_threshold · enable_partitionwise_join · plan_cache_mode · random_page_cost · effective_cache_size

参考资料

7 - effective_cache_size

规划器对单条查询可用 PostgreSQL 数据缓存规模的估计;它影响成本计算,但不会分配内存。
说明

Fact — 官方简述译文:设置规划器对有效数据缓存总规模的假设。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 , 8kB
原始单位
范围 , 12147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Cost Constants
上游分类
最后 boot 值 , 524288
4 GiB (524288 × 8kB)

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.0–9.3 16384 8kB 128 MiB (16384 × 8kB)
PG9.4–19 Beta 3 524288 8kB 4 GiB (524288 × 8kB)

机制详解

effective_cache_size 是成本模型输入。数值越高,索引扫描看起来越有吸引力;数值越低,顺序扫描越有吸引力。

估算时应同时考虑 shared_buffers 与操作系统页缓存中可能用于 PostgreSQL 数据的部分,也要考虑二者内容重叠,以及多个并发查询共同争用缓存容量。

修改此参数不会改变 PostgreSQL 共享内存大小、不会预留内核缓存,也不保证页面在查询之间持续驻留;它只通过执行计划选择间接生效。

调优建议

提示

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

场景 建议
OLTP 估算扣除操作系统和同机服务后 PostgreSQL 实际可用的缓存,再用 EXPLAIN 验证索引密集型计划。不要照搬并发与工作集完全不同的主机百分比。
OLAP 大扫描会驱逐或争用缓存,因此不能把已安装内存直接等同于单条分析查询可用缓存;应结合代表性的混合负载与冷缓存测试校准。
小规格 为操作系统与其他服务留出空间;共享的小主机若把它设置为接近总内存,通常会高估缓存。始终把它当规划器估计值,而不是内存目标。

Pigsty 取值

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

模板 有效值 与上游 boot 比较 源表达式
OLTP 24576MB 不同于 boot 值 {{ pg_effective_cache_size }}MB
OLAP 24576MB 不同于 boot 值 {{ pg_effective_cache_size }}MB
CRIT 24576MB 不同于 boot 值 {{ pg_effective_cache_size }}MB
TINY 24576MB 不同于 boot 值 {{ pg_effective_cache_size }}MB
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 = 24576MB (dcs);OLAP: PG9.0–19 Beta 3 = 24576MB (dcs);CRIT: PG9.0–19 Beta 3 = 24576MB (dcs);TINY: PG9.0–19 Beta 3 = 24576MB (dcs)。 建议(待人工复核)——编辑推断:把该余量作为规划器有效缓存估计是一项简化,需要结合实际 OS 缓存、内容重叠、同机服务与查询并发复核。

常见坑

  • 期待该设置实际分配或预留内存。
  • 不扣除 PostgreSQL 缓存无法使用的内存,直接设置为整机 RAM。
  • 忽略访问不同数据集的并发查询会共享有效缓存。
  • 高估取值后,把过度偏向索引的计划误归因于其他成本参数。

shared_buffers · random_page_cost · seq_page_cost · effective_io_concurrency · max_connections

参考资料

8 - enable_async_append

enable_async_append:允许规划器使用异步 Append 计划。实测在档范围为 PG14–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用异步 Append 计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG14
在档版本 PG14–19 Beta 3
移除版本
引入提交 27e1f14563cf — Add support for asynchronous execution.
提交日期 2021-03-31
Discussion 讨论 1 · 讨论 2 · 讨论 3

默认值变迁

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

机制详解

enable_async_append 控制规划器是否可以选择异步感知 Append;它可在多个支持异步访问的子计划之间重叠等待。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断异步感知 Append;它可在多个支持异步访问的子计划之间重叠等待是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_async_append,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_async_append 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG14–19 Beta 3 未修改;OLAP: PG14–19 Beta 3 未修改;CRIT: PG14–19 Beta 3 未修改;TINY: PG14–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_async_append 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_parallel_append · effective_io_concurrency · io_method · enable_partition_pruning

参考资料

9 - enable_bitmapscan

enable_bitmapscan:允许规划器使用位图扫描计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用位图扫描计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_bitmapscan 控制规划器是否可以选择位图索引与位图堆扫描;它先合并元组位置,再访问堆页面。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断位图索引与位图堆扫描;它先合并元组位置,再访问堆页面是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_bitmapscan,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_bitmapscan 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_bitmapscan 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_indexscan · enable_seqscan · random_page_cost · work_mem · effective_io_concurrency

参考资料

10 - enable_distinct_reordering

enable_distinct_reordering:允许规划器重排 DISTINCT 键。实测在档范围为 PG18–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器重排 DISTINCT 键。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG18
在档版本 PG18–19 Beta 3
移除版本
引入提交 a8ccf4e93a7e — Reordering DISTINCT keys to match input path’s pathkeys
提交日期 2024-11-26
Discussion 讨论 1

默认值变迁

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

机制详解

enable_distinct_reordering 控制规划器是否可以选择重排 DISTINCT 键以匹配有用的输入排序键,从而避免或缩小排序。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 保留 PG18 默认 on。怀疑回归时比较会话级计划,并验证重排后的 DISTINCT 键是真正匹配有用输入 pathkeys,还是只把一种排序换成另一种。
OLAP 大型 DISTINCT 在重排可利用索引、归并或已有顺序时可能获益。应测排序内存、落盘量、规划时间与总执行,不能因一个计划就全局关闭优化。
小规格 除非证明存在可复现计划回归,否则保持 on。若排序落盘,应先修正 work_mem 与计划输入,而不是把该规划器开关当作永久 hint。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG18–19 Beta 3 未修改;OLAP: PG18–19 Beta 3 未修改;CRIT: PG18–19 Beta 3 未修改;TINY: PG18–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_distinct_reordering 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_sort · enable_incremental_sort · enable_presorted_aggregate · work_mem

参考资料

11 - enable_eager_aggregate

enable_eager_aggregate:允许规划器把部分聚合提前推过连接。实测在档范围为 PG19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器把部分聚合提前推过连接。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG19 Beta 3
在档版本 PG19 Beta 3
移除版本
引入提交 8e11859102f9 — Implement Eager Aggregation
提交日期 2025-10-08
Discussion 讨论 1

默认值变迁

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

机制详解

enable_eager_aggregate:允许规划器把部分聚合提前推过连接。它可以按会话修改,便于在不影响全部负载的前提下比较计划或行为。 本站在 PG19 Beta 3 实测到它;boot_val 是编译或初始化基线,并不能证明某个运行集群的当前有效值。

提前聚合会把部分聚合下推到连接之前,从而减少穿过连接的行数,再在全部关系连接后完成最终聚合。只有估算平均分组尺寸达到 min_eager_agg_group_size 才会考虑;基数估算、分组语义、内存和其他连接路径仍决定规划器是否采用。

应与 min_eager_agg_group_size、enable_hashagg、enable_partitionwise_aggregate、work_mem 一起理解。请在目标服务器检查 SHOW 与 pg_settings,确认 source 和 pending_restart,并在修改前后对比真实负载、日志和资源指标。

调优建议

提示

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

场景 建议
OLTP 先按会话使用 EXPLAIN (ANALYZE, BUFFERS) 和有代表性的参数分布实验。只有提前聚合能稳定减少行数和延迟、且不引入计划抖动时才偏离默认值。
OLAP 测试确有预聚合机会的连接,并覆盖新旧统计信息与落盘压力;比较总 CPU、峰值内存、中间行数和并行计划,而不只看一次耗时。
小规格 在定位出可复现回归前保持规划器开关与阈值默认。先修复基数统计;全局强制路径常会用一个查询的收益换来更多回归。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG19 Beta 3 未修改;OLAP: PG19 Beta 3 未修改;CRIT: PG19 Beta 3 未修改;TINY: PG19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_eager_aggregate 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
  • 忽略 pg_settings 报告的 user context,误以为修改会立即生效。
  • 孤立修改该参数,没有检查关联上限、可观测性和回滚路径。
  • 在生产中依赖测试版行为,却没有在 PostgreSQL 19 正式版发布后重新验证。

min_eager_agg_group_size · enable_hashagg · enable_partitionwise_aggregate · work_mem · hash_mem_multiplier

参考资料

12 - enable_gathermerge

enable_gathermerge:允许规划器使用 Gather Merge 计划。实测在档范围为 PG10–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用 Gather Merge 计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG10
在档版本 PG10–19 Beta 3
移除版本
引入提交 355d3993c53e — Add a Gather Merge executor node.
提交日期 2017-03-09
Discussion 讨论 1

默认值变迁

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

机制详解

enable_gathermerge 控制规划器是否可以选择Gather Merge;它在合并并行 worker 输出时保留顺序。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断Gather Merge;它在合并并行 worker 输出时保留顺序是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_gathermerge,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_gathermerge 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG10–19 Beta 3 未修改;OLAP: PG10–19 Beta 3 未修改;CRIT: PG10–19 Beta 3 未修改;TINY: PG10–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_gathermerge 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

max_parallel_workers_per_gather · enable_sort · enable_incremental_sort · parallel_leader_participation

参考资料

13 - enable_group_by_reordering

enable_group_by_reordering:允许规划器重排 GROUP BY 键。实测在档范围为 PG17–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器重排 GROUP BY 键。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG17
在档版本 PG17–19 Beta 3
移除版本
引入提交 db0d67db2401 — Optimize order of GROUP BY keys
提交日期 2022-03-31
Discussion 讨论 1 · 讨论 2

默认值变迁

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

机制详解

enable_group_by_reordering 控制规划器是否可以选择重排 GROUP BY 键以匹配子节点路径键并利用已有顺序。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 保留默认 on。计划回归时在会话内比较 on/off,并检查重排 GROUP BY 键是否利用子节点已有 pathkeys,还是增加规划工作却没有避免排序。
OLAP 大型分组可能利用索引或预排序输入。为报表角色修改前,应评估排序与聚合节点、落盘、规划时间及结果顺序要求。
小规格 除非隔离出可重复回归,否则保持 on。把 off 当作局部绕行前,先解决陈旧统计、缺失排序路径与 work_mem 压力。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG17–19 Beta 3 未修改;OLAP: PG17–19 Beta 3 未修改;CRIT: PG17–19 Beta 3 未修改;TINY: PG17–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_group_by_reordering 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_sort · enable_incremental_sort · enable_hashagg · enable_presorted_aggregate

参考资料

14 - enable_hashagg

enable_hashagg:允许规划器使用哈希聚合计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用哈希聚合计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_hashagg 控制规划器是否可以选择哈希聚合;它在哈希表中分组,而不是依赖已排序的输入流。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断哈希聚合;它在哈希表中分组,而不是依赖已排序的输入流是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_hashagg,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_hashagg 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_hashagg 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

work_mem · hash_mem_multiplier · enable_sort · enable_partitionwise_aggregate

参考资料

15 - enable_hashjoin

enable_hashjoin:允许规划器使用哈希连接计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用哈希连接计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_hashjoin 控制规划器是否可以选择哈希连接;它为一侧输入建立哈希表,再用另一侧探测。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断哈希连接;它为一侧输入建立哈希表,再用另一侧探测是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_hashjoin,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_hashjoin 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_hashjoin 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

work_mem · hash_mem_multiplier · enable_parallel_hash · enable_mergejoin · enable_nestloop

参考资料

16 - enable_incremental_sort

enable_incremental_sort:允许规划器使用增量排序步骤。实测在档范围为 PG13–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用增量排序步骤。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG13
在档版本 PG13–19 Beta 3
移除版本
引入提交 94e454cddfba — Rename enable_incrementalsort for clarity
提交日期 2020-07-05
Discussion 讨论 1

默认值变迁

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

机制详解

enable_incremental_sort 控制规划器是否可以选择增量排序;它利用输入已按目标键前缀有序,只在各组内部继续排序。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断增量排序;它利用输入已按目标键前缀有序,只在各组内部继续排序是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_incremental_sort,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_incremental_sort 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG13–19 Beta 3 未修改;OLAP: PG13–19 Beta 3 未修改;CRIT: PG13–19 Beta 3 未修改;TINY: PG13–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_incremental_sort 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_sort · enable_gathermerge · work_mem · enable_presorted_aggregate

参考资料

17 - enable_indexonlyscan

enable_indexonlyscan:允许规划器使用仅索引扫描计划。实测在档范围为 PG9.2–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用仅索引扫描计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.2
在档版本 PG9.2–19 Beta 3
移除版本
引入提交 a2822fb9337a — Support index-only scans using the visibility map to avoid heap fetches.
提交日期 2011-10-07
Discussion

默认值变迁

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

机制详解

enable_indexonlyscan 控制规划器是否可以选择仅索引扫描;当可见性信息允许时,它可直接返回索引元组而不读堆。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

只有 enable_indexscan 同时开启时它才有效;未标记 all-visible 的堆页面仍需回表。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断仅索引扫描;当可见性信息允许时,它可直接返回索引元组而不读堆是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_indexonlyscan,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_indexonlyscan 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.2–19 Beta 3 未修改;OLAP: PG9.2–19 Beta 3 未修改;CRIT: PG9.2–19 Beta 3 未修改;TINY: PG9.2–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_indexonlyscan 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 只有 enable_indexscan 同时开启时它才有效;未标记 all-visible 的堆页面仍需回表。

enable_indexscan · enable_bitmapscan · enable_seqscan · random_page_cost · track_counts

参考资料

18 - enable_indexscan

enable_indexscan:允许规划器使用索引扫描计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用索引扫描计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_indexscan 控制规划器是否可以选择普通索引扫描;该开关同时是考虑仅索引扫描的前置条件。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断普通索引扫描;该开关同时是考虑仅索引扫描的前置条件是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_indexscan,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_indexscan 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_indexscan 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_indexonlyscan · enable_bitmapscan · enable_seqscan · random_page_cost · effective_cache_size

参考资料

19 - enable_material

enable_material:允许规划器插入物化节点。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器插入物化节点。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_material 控制规划器是否可以选择规划器插入的 Materialize 节点;它保存输入以供重复扫描或隔离执行属性。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

关闭它也不能删除正确性所必需的物化,只会阻止规划器插入可选物化。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断规划器插入的 Materialize 节点;它保存输入以供重复扫描或隔离执行属性是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_material,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_material 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_material 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 关闭它也不能删除正确性所必需的物化,只会阻止规划器插入可选物化。

work_mem · temp_file_limit · enable_memoize · enable_nestloop

参考资料

20 - enable_memoize

enable_memoize:允许规划器使用 Memoize 缓存节点。实测在档范围为 PG14–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用 Memoize 缓存节点。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG14
在档版本 PG14–19 Beta 3
移除版本
引入提交 47ca4836441d — Change the name of the Result Cache node to Memoize
提交日期 2021-07-14
Discussion 讨论 1

默认值变迁

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

机制详解

enable_memoize 控制规划器是否可以选择Memoize 节点;它在嵌套循环连接中缓存参数化内侧扫描的结果。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断Memoize 节点;它在嵌套循环连接中缓存参数化内侧扫描的结果是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_memoize,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_memoize 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG14–19 Beta 3 未修改;OLAP: PG14–19 Beta 3 未修改;CRIT: PG14–19 Beta 3 未修改;TINY: PG14–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_memoize 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_nestloop · work_mem · enable_material · cpu_operator_cost

参考资料

21 - enable_mergejoin

enable_mergejoin:允许规划器使用归并连接计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用归并连接计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_mergejoin 控制规划器是否可以选择归并连接;它消费按兼容连接键排序的两侧输入。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断归并连接;它消费按兼容连接键排序的两侧输入是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_mergejoin,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_mergejoin 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_mergejoin 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_hashjoin · enable_nestloop · enable_sort · enable_indexscan · work_mem

参考资料

22 - enable_nestloop

enable_nestloop:允许规划器使用嵌套循环连接计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用嵌套循环连接计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_nestloop 控制规划器是否可以选择嵌套循环连接,包括外侧很小时可能最优的参数化内侧扫描。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

关闭只会抑制嵌套循环,因为有些连接没有其他正确实现。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断嵌套循环连接,包括外侧很小时可能最优的参数化内侧扫描是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_nestloop,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_nestloop 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_nestloop 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 关闭只会抑制嵌套循环,因为有些连接没有其他正确实现。

enable_hashjoin · enable_mergejoin · enable_memoize · random_page_cost · work_mem

参考资料

23 - enable_parallel_append

enable_parallel_append:允许规划器使用并行感知的 Append 计划。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用并行感知的 Append 计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 ab7271677812 — Support Parallel Append plan nodes.
提交日期 2017-12-05
Discussion 讨论 1

默认值变迁

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

机制详解

enable_parallel_append 控制规划器是否可以选择并行感知 Append;它让 worker 在多个子计划之间分配工作。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断并行感知 Append;它让 worker 在多个子计划之间分配工作是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_parallel_append,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_parallel_append 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_parallel_append 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_async_append · max_parallel_workers_per_gather · enable_partition_pruning · parallel_leader_participation

参考资料

24 - enable_parallel_hash

enable_parallel_hash:允许规划器使用并行哈希计划。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用并行哈希计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 1804284042e6 — Add parallel-aware hash joins.
提交日期 2017-12-20
Discussion 讨论 1

默认值变迁

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

机制详解

enable_parallel_hash 控制规划器是否可以选择并行哈希;多个 worker 协同建立并探测共享哈希表。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

enable_hashjoin 关闭时它无效,并且还依赖并行安全计划和可用 worker。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断并行哈希;多个 worker 协同建立并探测共享哈希表是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_parallel_hash,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_parallel_hash 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_parallel_hash 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • enable_hashjoin 关闭时它无效,并且还依赖并行安全计划和可用 worker。

enable_hashjoin · max_parallel_workers_per_gather · work_mem · hash_mem_multiplier

参考资料

25 - enable_partition_pruning

enable_partition_pruning:允许在规划和执行阶段裁剪分区。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许在规划和执行阶段裁剪分区。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 055fb8d33da6 — Add GUC enable_partition_pruning
提交日期 2018-04-23
Discussion 讨论 1

默认值变迁

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

机制详解

enable_partition_pruning 控制规划器是否可以选择在规划和执行阶段排除与查询条件矛盾的分区。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断在规划和执行阶段排除与查询条件矛盾的分区是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_partition_pruning,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_partition_pruning 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_partition_pruning 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

constraint_exclusion · enable_partitionwise_join · enable_partitionwise_aggregate · plan_cache_mode

参考资料

26 - enable_partitionwise_aggregate

enable_partitionwise_aggregate:允许按分区执行聚合与分组。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 off,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许按分区执行聚合与分组。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , off
off

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 e2f1eb0ee30d — Implement partition-wise grouping/aggregation.
提交日期 2018-03-22
Discussion 讨论 1

默认值变迁

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

机制详解

enable_partitionwise_aggregate 控制规划器是否可以选择按分区分组或聚合;分组键不含分区键时再执行最终汇总。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

参与分区增多时,它可能近似线性地增加受 work_mem 限制的节点和规划成本。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断按分区分组或聚合;分组键不含分区键时再执行最终汇总是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_partitionwise_aggregate,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_partitionwise_aggregate 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 = on (dcs);CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):仅 OLAP 覆盖意在分析型分区模型上利用分区内聚合,同时避免其他模板承担规划与内存放大。

常见坑

  • 把 enable_partitionwise_aggregate 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 参与分区增多时,它可能近似线性地增加受 work_mem 限制的节点和规划成本。

enable_partitionwise_join · enable_partition_pruning · work_mem · enable_hashagg · max_parallel_workers_per_gather

参考资料

27 - enable_partitionwise_join

enable_partitionwise_join:允许按匹配分区执行连接。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 off,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许按匹配分区执行连接。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , off
off

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 2fb1abaeb016 — Rename enable_partition_wise_join to enable_partitionwise_join
提交日期 2018-02-16
Discussion 讨论 1

默认值变迁

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

机制详解

enable_partitionwise_join 控制规划器是否可以选择当连接键包含兼容分区键时,对一一匹配的分区分别执行连接。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

参与分区增多时,它可能近似线性地增加受 work_mem 限制的节点和规划成本。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 保持上游默认 off。只有两侧是一一兼容分区布局且连接包含全部分区键时,才在会话范围测试 on;同时预算每分区产生的规划 CPU 与受 work_mem 限制节点。
OLAP 分区对齐的分析连接可能从 on 获益,这也是当前 Pigsty OLAP 模板启用它的背景。应比较规划内存、规划时间、总执行内存与分区数,不能只看执行时间。
小规格 除非特定分区对齐连接反复获益,否则保持 off。分区很多时,即使每个局部连接高效,规划与每节点内存也可能在小主机上失衡。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 = on (dcs);CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):仅 OLAP 覆盖意在分析型连接中利用匹配分区布局,同时避免其他模板承担更广泛的规划与内存成本。

常见坑

  • 把 enable_partitionwise_join 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 参与分区增多时,它可能近似线性地增加受 work_mem 限制的节点和规划成本。

enable_partitionwise_aggregate · enable_partition_pruning · work_mem · join_collapse_limit · max_parallel_workers_per_gather

参考资料

28 - enable_presorted_aggregate

enable_presorted_aggregate:允许规划器为带 ORDER BY 或 DISTINCT 的聚合提供预排序输入。实测在档范围为 PG16–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器为带 ORDER BY 或 DISTINCT 的聚合提供预排序输入。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG16
在档版本 PG16–19 Beta 3
移除版本
引入提交 3226f47282a0 — Add enable_presorted_aggregate GUC
提交日期 2022-12-20
Discussion 讨论 1

默认值变迁

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

机制详解

enable_presorted_aggregate 控制规划器是否可以选择为聚合函数的 ORDER BY 或 DISTINCT 子句直接提供已排序输入的计划。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断为聚合函数的 ORDER BY 或 DISTINCT 子句直接提供已排序输入的计划是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_presorted_aggregate,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_presorted_aggregate 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG16–19 Beta 3 未修改;OLAP: PG16–19 Beta 3 未修改;CRIT: PG16–19 Beta 3 未修改;TINY: PG16–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_presorted_aggregate 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_sort · enable_incremental_sort · enable_group_by_reordering · work_mem

参考资料

29 - enable_self_join_elimination

enable_self_join_elimination:允许消除可证明冗余的唯一自连接。实测在档范围为 PG18–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许消除可证明冗余的唯一自连接。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG18
在档版本 PG18–19 Beta 3
移除版本
引入提交 fc069a3a6319 — Implement Self-Join Elimination
提交日期 2025-02-13
Discussion 讨论 1

默认值变迁

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

机制详解

enable_self_join_elimination 控制规划器是否可以选择在唯一性与谓词能保持语义时,删除普通表上可证明冗余的自连接。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该优化仅适用于普通表,并要求能证明删除重复关系不改变结果。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 保留 PG18 默认 on。怀疑回归时只在单个会话比较 on/off,并检查唯一性证明与谓词是否允许删除普通表冗余自连接;不要通过全局关闭掩盖估算问题。
OLAP 自连接消除可减少生成式分析 SQL 的扫描与连接工作。应在代表性语句上验证计划形态与结果等价,并记住它仅适用于普通表和可证明唯一的情况。
小规格 除非隔离出可复现的 PG18 规划器回归,否则保持 on。该开关不会删除任意自连接;缺少证明条件时仍需正确查询与索引设计。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG18–19 Beta 3 未修改;OLAP: PG18–19 Beta 3 未修改;CRIT: PG18–19 Beta 3 未修改;TINY: PG18–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_self_join_elimination 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该优化仅适用于普通表,并要求能证明删除重复关系不改变结果。

join_collapse_limit · from_collapse_limit · enable_nestloop · enable_hashjoin

参考资料

30 - enable_seqscan

enable_seqscan:允许规划器使用顺序扫描计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用顺序扫描计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_seqscan 控制规划器是否可以选择顺序扫描;它按物理页面次序读取关系。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

关闭只会抑制顺序扫描,因为有些查询仍没有可用替代路径。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断顺序扫描;它按物理页面次序读取关系是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_seqscan,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_seqscan 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_seqscan 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 关闭只会抑制顺序扫描,因为有些查询仍没有可用替代路径。

enable_indexscan · enable_bitmapscan · seq_page_cost · random_page_cost · effective_cache_size

参考资料

31 - enable_sort

enable_sort:允许规划器使用显式排序步骤。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用显式排序步骤。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_sort 控制规划器是否可以选择在没有可用输入顺序满足目标路径键时插入显式 Sort 节点。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

关闭只会抑制显式排序,因为正确性仍可能要求排序。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断在没有可用输入顺序满足目标路径键时插入显式 Sort 节点是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_sort,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_sort 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_sort 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 关闭只会抑制显式排序,因为正确性仍可能要求排序。

work_mem · temp_file_limit · enable_incremental_sort · enable_gathermerge · trace_sort

参考资料

32 - enable_tidscan

enable_tidscan:允许规划器使用 TID 扫描计划。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:允许规划器使用 TID 扫描计划。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Method Configuration
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

enable_tidscan 控制规划器是否可以选择针对 ctid 等物理元组位置谓词的 TID 扫描。

该值在生成计划时读取。会话级修改适合比较不同 EXPLAIN 方案,但不会追溯改写已缓存计划;必须触发失效或重新规划才能观察到不同选择。

该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 常规 OLTP 应保留上游默认值。可在事务或会话内临时修改以诊断针对 ctid 等物理元组位置谓词的 TID 扫描是否导致回归,随后修复统计信息、索引、估算或查询形态,不要留下集群级方法禁令。
OLAP 应对代表性分析计划分别测试开启与关闭 enable_tidscan,同时评估规划时间、内存、落盘和执行时间;单份报表获益不能证明适合全局修改。
小规格 不要把 enable_tidscan 当作小主机上的永久 hint。资源压力会改变最佳方法,应使用 EXPLAIN (ANALYZE, BUFFERS) 验证;确有需要也应把范围限制到相关负载。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 enable_tidscan 当成单条查询 hint,却忽略它会影响作用域内生成的所有计划。
  • 用已经缓存的预备计划测试,然后误判该参数没有效果。
  • 通过全局禁用计划方法来掩盖统计信息陈旧或基数估算错误。
  • 该开关改变规划器可以计价的候选路径,并不会让已选中的方法本身变快。

enable_indexscan · enable_seqscan · random_page_cost · cpu_tuple_cost

参考资料

33 - from_collapse_limit

from_collapse_limit:设置不再折叠子查询的 FROM 列表规模阈值。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 8,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置不再折叠子查询的 FROM 列表规模阈值。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 12147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , 8
8

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

from_collapse_limit 限制规划器把可折叠子查询合并到上层 FROM 列表的程度。展平会暴露更多连接顺序与谓词移动机会,也会扩大搜索空间。

若展平会产生超过阈值的 FROM 项,子查询边界就会保留。较小值可缩短规划时间,但可能隐藏更好的全局连接顺序。

最终关系数会与 join_collapse_limit 和 geqo_threshold 联动;提高本值可能让查询意外从穷举规划切换到 GEQO。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 from_collapse_limit 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,from_collapse_limit 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 from_collapse_limit 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 from_collapse_limit 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

join_collapse_limit · geqo_threshold · geqo · plan_cache_mode

参考资料

34 - geqo

geqo:启用遗传查询优化。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 on,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:启用遗传查询优化。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , on
on

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

对足够大的连接问题,它选择启发式 GEQO 连接顺序搜索,而不是穷举式动态规划。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo_threshold · geqo_effort · geqo_pool_size · geqo_generations · join_collapse_limit

参考资料

35 - geqo_effort

geqo_effort:设置 GEQO 用于推导其他参数默认值的工作强度。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 5,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 GEQO 用于推导其他参数默认值的工作强度。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 110
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 5
5

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它是 1 到 10 的便捷旋钮,用于推导种群规模与代数默认值;它不直接参与遗传算法步骤。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_effort 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_effort,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_effort 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_pool_size · geqo_generations · geqo_selection_bias · geqo_threshold

参考资料

36 - geqo_generations

geqo_generations:设置 GEQO 算法迭代代数。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 GEQO 算法迭代代数。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 02147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 0
0

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它设置进化迭代代数;零表示根据所选种群规模推导。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_generations 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_generations,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_generations 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_pool_size · geqo_effort · geqo_seed · geqo_selection_bias

参考资料

37 - geqo_pool_size

geqo_pool_size:设置 GEQO 种群中的个体数。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 GEQO 种群中的个体数。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 02147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 0
0

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它设置遗传种群中的候选连接顺序数;零表示让 PostgreSQL 根据 effort 与查询规模推导。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_pool_size 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_pool_size,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_pool_size 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_effort · geqo_generations · geqo_selection_bias · geqo_seed

参考资料

38 - geqo_seed

geqo_seed:设置 GEQO 随机路径选择的种子。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 GEQO 随机路径选择的种子。

身份

类型 , real
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 01
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 0
0

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它为 GEQO 随机路径选择设种。修改它会探索不同的连接顺序子集,不会改变表数据或统计信息。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_seed 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_seed,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_seed 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_pool_size · geqo_generations · geqo_selection_bias · geqo_threshold

参考资料

39 - geqo_selection_bias

geqo_selection_bias:设置 GEQO 种群内的选择压力。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 2,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 GEQO 种群内的选择压力。

身份

类型 , real
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 1.52
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 2
2

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它控制选择压力:较高值更强地偏好高适应度候选,但也会降低种群多样性。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_selection_bias 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_selection_bias,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_selection_bias 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_pool_size · geqo_generations · geqo_seed · geqo_effort

参考资料

40 - geqo_threshold

geqo_threshold:设置 FROM 项达到多少时改用 GEQO。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 12,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 FROM 项达到多少时改用 GEQO。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 22147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Genetic Query Optimizer
上游分类
最后 boot 值 , 12
12

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

它统计 FROM 项,在达到阈值时把符合条件的连接问题切换到 GEQO;一个 FULL OUTER JOIN 构造只算一项。

GEQO 以可能错过最佳连接顺序为代价,把规划时间控制在启发式搜索范围内。构造候选之后,它仍使用普通规划器成本模型为扫描与连接路径计价。

该值在规划阶段读取;GEQO 的随机搜索意味着计划质量会随种子与搜索预算变化。折叠阈值会改变暴露给连接搜索的关系数,因此也会影响是否越过 GEQO 阈值。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非实测多表连接规划时间有问题,否则保留 geqo_threshold 上游默认值。全局扩大随机搜索预算前,应先简化生成 SQL 或修复连接估算。
OLAP 对反复执行的多表报表,应在多个 geqo_seed 下测试 geqo_threshold,同时比较规划与执行时间。偶然命中的好种子不是稳定生产策略。
小规格 小主机上不要通过调整 geqo_threshold 消耗不成比例的规划 CPU。默认自适应取值通常比照搬大系统搜索预算更安全。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 只根据一次随机 GEQO 运行判断计划质量。
  • 调整 GEQO 旋钮却没有考虑 geqo_threshold 与折叠阈值。
  • 为微小或不稳定的执行收益付出大幅规划 CPU。
  • 误以为 GEQO 保证找到全局最佳连接顺序。

geqo · geqo_effort · join_collapse_limit · from_collapse_limit · geqo_seed

参考资料

41 - jit

当构建包含可用的 JIT 实现且计划估算成本越过阈值时,允许 PostgreSQL 使用即时编译。开启并不意味着每条查询都会执行 JIT。
说明

Fact — 官方简述译文:在 JIT 可用且成本规则选中查询时允许即时编译。

身份

类型 , bool
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , off
off

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 432bb9e04da4 — Basic JIT provider and error handling infrastructure.
提交日期 2018-03-21
Discussion 讨论 1

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG11 off off
PG12–18 on on
PG19 Beta 3 off off

机制详解

jit 是总开关。开启后,jit_above_cost 决定是否开始编译,jit_inline_above_cost 与 jit_optimize_above_cost 控制额外且成本更高的内联和优化工作。

JIT 主要有利于运行时间长、CPU 密集的查询,常见于分析负载。编译本身增加延迟,因此过度降低阈值可能让短语句更慢。

决策发生在规划阶段。使用通用计划的预备语句由生成该计划时的配置决定;EXPLAIN ANALYZE 会显示 JIT 是否执行以及各阶段耗时。

调优建议

提示

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

场景 建议
OLTP 保持较高默认阈值;若短请求尾延迟中出现编译开销,可关闭 JIT。应先按语句或角色测试,再考虑全局修改。
OLAP 保持可用,并针对 CPU 密集的聚合、表达式和扫描做基准;评估总执行时间时必须包含生成、内联、优化和代码发射开销。
小规格 小型且 CPU 受限系统上的普通查询通常获益有限。保持开启并使用保守阈值,与降低阈值强制编译是两回事。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 若 PostgreSQL 构建没有可用 JIT 实现,jit=on 也不会生效。
  • 开启不等于每条查询都编译,成本阈值仍会筛选。
  • 降低阈值可能让短查询比解释执行更慢。
  • 通用预备计划采用生成计划时的配置。
  • 估算成本不是执行时间,必须用代表性计划实测阈值效果。

jit_above_cost · jit_inline_above_cost · jit_optimize_above_cost · jit_provider · plan_cache_mode · jit_expressions

参考资料

42 - jit_above_cost

jit_above_cost:设置启用 JIT 编译的查询成本阈值。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 100000,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置启用 JIT 编译的查询成本阈值。

身份

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

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 cc415a56d09a — Basic planner and executor integration for JIT.
提交日期 2018-03-22
Discussion 讨论 1

默认值变迁

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

机制详解

jit_above_cost 把最终计划的估算成本与阈值比较,决定 PostgreSQL 是否可以开始 JIT 编译。这里的成本是规划器任意单位的估计,并非毫秒。

决策发生在规划阶段,且只有 jit 已开启并存在可用 provider 时才有意义。通用预备计划会保留生成该通用计划时作出的决定。

设置为 -1 会关闭该阶段。jit_inline_above_cost 与 jit_optimize_above_cost 是越过 jit_above_cost 后的附加门槛,因此把它们设得低于基础编译阈值没有意义。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 不要为一条 CPU 密集语句全局降低 jit_above_cost。短查询尾延迟会直接承受编译开销;应按语句或角色测试,并把 JIT 生成时间计入结果。
OLAP 对长时间 CPU 密集查询,应在 jit_above_cost 阈值两侧比较总耗时。只有节省的执行 CPU 能稳定覆盖编译开销时,降低阈值才有价值。
小规格 保持默认值;当 LLVM 工作会争抢有限 CPU 时可用 -1 关闭相应阶段。估算成本高并不能证明 JIT 一定收回启动成本。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把阈值误读为毫秒,而不是规划器任意成本单位。
  • 基准测试时忽略 JIT 生成、内联、优化和代码发射时间。
  • 期望修改该值后已生成的通用计划会自动改变。
  • 把附加阶段阈值设得低于 jit_above_cost,并误以为该阶段能独立运行。

jit · jit_inline_above_cost · jit_optimize_above_cost · jit_expressions

参考资料

43 - jit_inline_above_cost

jit_inline_above_cost:设置 JIT 尝试内联的查询成本阈值。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 500000,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 JIT 尝试内联的查询成本阈值。

身份

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

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 9370462e9a79 — Add inlining support to LLVM JIT provider.
提交日期 2018-03-28
Discussion 讨论 1

默认值变迁

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

机制详解

jit_inline_above_cost 把最终计划的估算成本与阈值比较,决定 PostgreSQL 是否可以执行 JIT 内联。这里的成本是规划器任意单位的估计,并非毫秒。

决策发生在规划阶段,且只有 jit 已开启并存在可用 provider 时才有意义。通用预备计划会保留生成该通用计划时作出的决定。

设置为 -1 会关闭该阶段。jit_inline_above_cost 与 jit_optimize_above_cost 是越过 jit_above_cost 后的附加门槛,因此把它们设得低于基础编译阈值没有意义。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 不要为一条 CPU 密集语句全局降低 jit_inline_above_cost。短查询尾延迟会直接承受编译开销;应按语句或角色测试,并把 JIT 生成时间计入结果。
OLAP 对长时间 CPU 密集查询,应在 jit_inline_above_cost 阈值两侧比较总耗时。只有节省的执行 CPU 能稳定覆盖编译开销时,降低阈值才有价值。
小规格 保持默认值;当 LLVM 工作会争抢有限 CPU 时可用 -1 关闭相应阶段。估算成本高并不能证明 JIT 一定收回启动成本。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把阈值误读为毫秒,而不是规划器任意成本单位。
  • 基准测试时忽略 JIT 生成、内联、优化和代码发射时间。
  • 期望修改该值后已生成的通用计划会自动改变。
  • 把附加阶段阈值设得低于 jit_above_cost,并误以为该阶段能独立运行。

jit · jit_above_cost · jit_optimize_above_cost · jit_expressions

参考资料

44 - jit_optimize_above_cost

jit_optimize_above_cost:设置 JIT 执行昂贵优化的查询成本阈值。实测在档范围为 PG11–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 500000,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置 JIT 执行昂贵优化的查询成本阈值。

身份

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

生命周期

Fact
首次观测 PG11
在档版本 PG11–19 Beta 3
移除版本
引入提交 cc415a56d09a — Basic planner and executor integration for JIT.
提交日期 2018-03-22
Discussion 讨论 1

默认值变迁

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

机制详解

jit_optimize_above_cost 把最终计划的估算成本与阈值比较,决定 PostgreSQL 是否可以执行昂贵的 JIT 优化过程。这里的成本是规划器任意单位的估计,并非毫秒。

决策发生在规划阶段,且只有 jit 已开启并存在可用 provider 时才有意义。通用预备计划会保留生成该通用计划时作出的决定。

设置为 -1 会关闭该阶段。jit_inline_above_cost 与 jit_optimize_above_cost 是越过 jit_above_cost 后的附加门槛,因此把它们设得低于基础编译阈值没有意义。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 不要为一条 CPU 密集语句全局降低 jit_optimize_above_cost。短查询尾延迟会直接承受编译开销;应按语句或角色测试,并把 JIT 生成时间计入结果。
OLAP 对长时间 CPU 密集查询,应在 jit_optimize_above_cost 阈值两侧比较总耗时。只有节省的执行 CPU 能稳定覆盖编译开销时,降低阈值才有价值。
小规格 保持默认值;当 LLVM 工作会争抢有限 CPU 时可用 -1 关闭相应阶段。估算成本高并不能证明 JIT 一定收回启动成本。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG11–19 Beta 3 未修改;OLAP: PG11–19 Beta 3 未修改;CRIT: PG11–19 Beta 3 未修改;TINY: PG11–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把阈值误读为毫秒,而不是规划器任意成本单位。
  • 基准测试时忽略 JIT 生成、内联、优化和代码发射时间。
  • 期望修改该值后已生成的通用计划会自动改变。
  • 把附加阶段阈值设得低于 jit_above_cost,并误以为该阶段能独立运行。

jit · jit_above_cost · jit_inline_above_cost · jit_expressions

参考资料

45 - join_collapse_limit

join_collapse_limit:设置不再展平 JOIN 构造的 FROM 列表规模阈值。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 8,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置不再展平 JOIN 构造的 FROM 列表规模阈值。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 , 12147483647
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , 8
8

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

join_collapse_limit 控制何时把显式 JOIN 构造(FULL JOIN 除外)展平为可重排的 FROM 列表。设置为 1 会保留 SQL 写出的显式连接顺序。

展平扩大规划器可探索的连接顺序集合,可能改善计划,但会消耗更多规划 CPU 与内存;外连接语义仍会限制合法重排。

暴露的项数会与 from_collapse_limit 和 geqo_threshold 联动。把 1 当作手工连接顺序工具会把责任转给 SQL 作者,并不构成通用计划稳定性保证。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 join_collapse_limit 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,join_collapse_limit 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 join_collapse_limit 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 join_collapse_limit 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

from_collapse_limit · geqo_threshold · geqo · enable_hashjoin · enable_nestloop

参考资料

46 - min_eager_agg_group_size

min_eager_agg_group_size:设置考虑提前聚合所需的最小平均分组大小。实测在档范围为 PG19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 8,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置考虑提前聚合所需的最小平均分组大小。

身份

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

生命周期

Fact
首次观测 PG19 Beta 3
在档版本 PG19 Beta 3
移除版本
引入提交 8e11859102f9 — Implement Eager Aggregation
提交日期 2025-10-08
Discussion 讨论 1

默认值变迁

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

机制详解

min_eager_agg_group_size:设置考虑提前聚合所需的最小平均分组大小。它可以按会话修改,便于在不影响全部负载的前提下比较计划或行为。 本站在 PG19 Beta 3 实测到它;boot_val 是编译或初始化基线,并不能证明某个运行集群的当前有效值。

这个成本阈值表示:估算每组平均至少有多少输入行,提前聚合才值得考虑。提高它会要求更明显的行数缩减;降低它会探索更多提前聚合路径,但可能把规划与执行开销花在几乎不能缩小连接输入的分组上。

应与 enable_eager_aggregate、enable_hashagg、enable_partitionwise_aggregate、work_mem 一起理解。请在目标服务器检查 SHOW 与 pg_settings,确认 source 和 pending_restart,并在修改前后对比真实负载、日志和资源指标。

调优建议

提示

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

场景 建议
OLTP 先按会话使用 EXPLAIN (ANALYZE, BUFFERS) 和有代表性的参数分布实验。只有提前聚合能稳定减少行数和延迟、且不引入计划抖动时才偏离默认值。
OLAP 测试确有预聚合机会的连接,并覆盖新旧统计信息与落盘压力;比较总 CPU、峰值内存、中间行数和并行计划,而不只看一次耗时。
小规格 在定位出可复现回归前保持规划器开关与阈值默认。先修复基数统计;全局强制路径常会用一个查询的收益换来更多回归。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG19 Beta 3 未修改;OLAP: PG19 Beta 3 未修改;CRIT: PG19 Beta 3 未修改;TINY: PG19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 min_eager_agg_group_size 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
  • 忽略 pg_settings 报告的 user context,误以为修改会立即生效。
  • 孤立修改该参数,没有检查关联上限、可观测性和回滚路径。
  • 在生产中依赖测试版行为,却没有在 PostgreSQL 19 正式版发布后重新验证。

enable_eager_aggregate · enable_hashagg · enable_partitionwise_aggregate · work_mem · hash_mem_multiplier

参考资料

47 - min_parallel_index_scan_size

min_parallel_index_scan_size:设置考虑并行索引扫描所需的最小索引数据量。实测在档范围为 PG10–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 512 KiB (64 × 8kB),context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置考虑并行索引扫描所需的最小索引数据量。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 , 8kB
原始单位
范围 , 0715827882
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Cost Constants
上游分类
最后 boot 值 , 64
512 KiB (64 × 8kB)

生命周期

Fact
首次观测 PG10
在档版本 PG10–19 Beta 3
移除版本
引入提交 51ee6f3160d2 — Replace min_parallel_relation_size with two new GUCs.
提交日期 2017-02-15
Discussion 讨论 1 · 讨论 2

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG10–19 Beta 3 64 8kB 512 KiB (64 × 8kB)

机制详解

min_parallel_index_scan_size 是规划器的候选资格下限:只有预计会访问的索引页面量达到配置规模时,才会考虑并行扫描路径。

越过该下限并不保证产生并行计划。规划器仍会比较成本、检查并行安全性,并受 max_parallel_workers_per_gather 与集群 worker 池约束。

索引阈值还参与判断索引能否并行 vacuum。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 提高 min_parallel_index_scan_size 可减少短 OLTP 扫描启动并行,但要确认报表与维护任务没有回归。Pigsty 的 OLTP/crit 取值是规划策略偏好,并非资源上限。
OLAP 除非较小但昂贵的扫描被错误排除,否则保留上游阈值。降低 min_parallel_index_scan_size 会在大量并发查询时增加规划与 worker 开销。
小规格 小主机上 worker 启动与内存竞争更突出,宜采用保守或更高阈值,并与 max_parallel_workers_per_gather 联动,而不是单独调整。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG10–19 Beta 3 = 2MB (dcs);OLAP: PG10–19 Beta 3 未修改;CRIT: PG10–19 Beta 3 = 2MB (dcs);TINY: PG10–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):OLTP/crit 取值提高索引并行候选下限以降低并行倾向,OLAP 与 tiny 保留上游行为。

常见坑

  • 误以为阈值限制实际读取字节;它只控制规划器候选资格。
  • 认为规模估计一越过阈值就必然产生并行计划。
  • 降低阈值却没有为并发下的 worker 与节点内存做预算。
  • 比较裸数值时忘记应用 8kB 块单位。

max_parallel_workers_per_gather · parallel_setup_cost · parallel_tuple_cost · max_parallel_workers · enable_indexscan

参考资料

48 - min_parallel_relation_size

min_parallel_relation_size:设置可考虑并行扫描的关系最小尺寸。实测在档范围为 PG9.6;最后在档的 PG9.6 启动默认值为 8 MiB (1024 × 8kB),context 为 user。它在 PG10 被移除。
说明

Fact — 官方简述译文:设置可考虑并行扫描的关系最小尺寸。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 , 8kB
原始单位
范围 , 0715827882
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Cost Constants
上游分类
最后 boot 值 , 1024
8 MiB (1024 × 8kB)

生命周期

Fact
首次观测 PG9.6
在档版本 PG9.6
移除版本 PG10
引入提交 75be66464cb1 — Invent min_parallel_relation_size GUC to replace a hard-wired constant.
提交日期 2016-06-16
Discussion

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.6 1024 8kB 8 MiB (1024 × 8kB)

机制详解

min_parallel_relation_size:设置可考虑并行扫描的关系最小尺寸。它可以按会话修改,便于在不影响全部负载的前提下比较计划或行为。 本站在 PG9.6 实测到它;boot_val 是编译或初始化基线,并不能证明某个运行集群的当前有效值。

PG9.6 使用单一关系尺寸阈值判断是否值得考虑并行扫描。PG10 将它拆成 min_parallel_table_scan_size 与 min_parallel_index_scan_size,让 heap 与索引访问路径拥有不同的盈亏平衡点。

应与 min_parallel_table_scan_size、min_parallel_index_scan_size、max_parallel_workers_per_gather、enable_parallel_append 一起理解。请在目标服务器检查 SHOW 与 pg_settings,确认 source 和 pending_restart,并在修改前后对比真实负载、日志和资源指标。

调优建议

提示

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

场景 建议
OLTP 不要把这个已退出的名称加入现代 OLTP 配置。应把原意迁移到文档给出的后继参数,在连接与写并发下验证,并清理仍会输出旧名称的自动化。
OLAP 升级分析型环境前应盘点所有生成配置,把旧控制映射到后继项,并比较执行计划、吞吐、WAL 或日志行为;不能假设旧数值可直接搬用。
小规格 记录旧覆盖存在的原因后将其删除。小节点应先采用后继参数默认值,实测后再调整;未知的启动参数可能直接阻止服务器启动。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.6 未修改;OLAP: PG9.6 未修改;CRIT: PG9.6 未修改;TINY: PG9.6 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 min_parallel_relation_size 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
  • 忽略 pg_settings 报告的 user context,误以为修改会立即生效。
  • 孤立修改该参数,没有检查关联上限、可观测性和回滚路径。
  • 把已移除名称复制到现代 postgresql.conf,而没有迁移到文档给出的后继参数。

min_parallel_table_scan_size · min_parallel_index_scan_size · max_parallel_workers_per_gather · enable_parallel_append

参考资料

49 - min_parallel_table_scan_size

min_parallel_table_scan_size:设置考虑并行表扫描所需的最小表数据量。实测在档范围为 PG10–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 8 MiB (1024 × 8kB),context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置考虑并行表扫描所需的最小表数据量。

身份

类型 , integer
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 , 8kB
原始单位
范围 , 0715827882
最后在档版本的原始上下限
枚举值 ,
非枚举类型记为 —
分类 , Query Tuning / Planner Cost Constants
上游分类
最后 boot 值 , 1024
8 MiB (1024 × 8kB)

生命周期

Fact
首次观测 PG10
在档版本 PG10–19 Beta 3
移除版本
引入提交 51ee6f3160d2 — Replace min_parallel_relation_size with two new GUCs.
提交日期 2017-02-15
Discussion 讨论 1 · 讨论 2

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG10–19 Beta 3 1024 8kB 8 MiB (1024 × 8kB)

机制详解

min_parallel_table_scan_size 是规划器的候选资格下限:只有预计会扫描的表数据量达到配置规模时,才会考虑并行扫描路径。

越过该下限并不保证产生并行计划。规划器仍会比较成本、检查并行安全性,并受 max_parallel_workers_per_gather 与集群 worker 池约束。

对并行顺序扫描,估算量通常是整个关系大小。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 提高 min_parallel_table_scan_size 可减少短 OLTP 扫描启动并行,但要确认报表与维护任务没有回归。Pigsty 的 OLTP/crit 取值是规划策略偏好,并非资源上限。
OLAP 除非较小但昂贵的扫描被错误排除,否则保留上游阈值。降低 min_parallel_table_scan_size 会在大量并发查询时增加规划与 worker 开销。
小规格 小主机上 worker 启动与内存竞争更突出,宜采用保守或更高阈值,并与 max_parallel_workers_per_gather 联动,而不是单独调整。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG10–19 Beta 3 = 32MB (dcs);OLAP: PG10–19 Beta 3 未修改;CRIT: PG10–19 Beta 3 = 32MB (dcs);TINY: PG10–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):OLTP/crit 取值提高表扫描并行候选下限以降低并行倾向,OLAP 与 tiny 保留上游行为。

常见坑

  • 误以为阈值限制实际读取字节;它只控制规划器候选资格。
  • 认为规模估计一越过阈值就必然产生并行计划。
  • 降低阈值却没有为并发下的 worker 与节点内存做预算。
  • 比较裸数值时忘记应用 8kB 块单位。

max_parallel_workers_per_gather · parallel_setup_cost · parallel_tuple_cost · max_parallel_workers · enable_seqscan

参考资料

50 - 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

参考资料

51 - parallel_tuple_cost

parallel_tuple_cost:设置把每行从并行 worker 传给 leader 的成本估计。实测在档范围为 PG9.6–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 0.1,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置把每行从并行 worker 传给 leader 的成本估计。

身份

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

生命周期

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 0.1 0.1

机制详解

parallel_tuple_cost 用于刻画把每行从并行 worker 传给另一个进程的开销。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

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

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

调优建议

提示

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

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

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.6–19 Beta 3 = 0.2 (dcs);OLAP: PG9.6–19 Beta 3 未修改;CRIT: PG9.6–19 Beta 3 = 0.2 (dcs);TINY: PG9.6–19 Beta 3 未修改。 建议(待人工复核)——编辑推断(待维护者复核):OLTP/crit 把元组传输估算翻倍,意在降低元组量大路径的并行计划倾向;OLAP 与 tiny 保留上游行为。

常见坑

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

parallel_setup_cost · max_parallel_workers_per_gather · parallel_leader_participation · enable_gathermerge

参考资料

52 - plan_cache_mode

plan_cache_mode:控制规划器选择自定义计划还是通用计划。实测在档范围为 PG12–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 auto,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:控制规划器选择自定义计划还是通用计划。

身份

类型 , enum
上游 pg_settings 类型
Context , user
普通用户可在运行时修改
单位 ,
原始单位
范围 ,
最后在档版本的原始上下限
枚举值 , auto, force_generic_plan, force_custom_plan
非枚举类型记为 —
分类 , Query Tuning / Other Planner Options
上游分类
最后 boot 值 , auto
auto

生命周期

Fact
首次观测 PG12
在档版本 PG12–19 Beta 3
移除版本
引入提交 f7cb2842bf47 — Add plan_cache_mode setting
提交日期 2018-07-16
Discussion 讨论 1

默认值变迁

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

机制详解

预备语句可以使用根据当前参数值生成的自定义计划,也可以使用与参数值无关的通用计划。plan_cache_mode 以 auto、force_custom_plan 或 force_generic_plan 覆盖 PostgreSQL 的正常成本选择。

该设置在执行缓存语句时检查,而不是在 PREPARE 时检查。自定义计划反复支付规划成本但能适应数据倾斜;通用计划节省规划工作,却可能不适合参数敏感谓词。

PL/pgSQL 和协议层预备语句都会受影响。强制模式是诊断或特定负载策略,不是修复统计信息不准或索引缺失的方法。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 plan_cache_mode 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,plan_cache_mode 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 plan_cache_mode 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG12–19 Beta 3 未修改;OLAP: PG12–19 Beta 3 未修改;CRIT: PG12–19 Beta 3 未修改;TINY: PG12–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 plan_cache_mode 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

default_statistics_target · cursor_tuple_fraction · join_collapse_limit · compute_query_id · jit_above_cost

参考资料

53 - random_page_cost

这是描述非顺序页面访问相对顺序访问成本的规划器常量。降低它会让索引和位图访问路径显得更便宜,但不会改变存储系统本身的行为。
说明

Fact — 官方简述译文:设置规划器对非顺序读取页面的相对成本估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

规划器成本单位是任意尺度,主要看各成本常量之间的相对关系。seq_page_cost 通常约定为 1.0,random_page_cost 则在考虑缓存命中与存储特性后描述随机访问的平均惩罚。

相对 seq_page_cost 降低本值会偏向索引扫描,提高则会让索引扫描显得更贵。两者都可按 tablespace 覆盖,适合一个集群存在多种存储层级的情况。

官方建议把这些常量视为整个查询组合的平均模型,并警告不要根据少量实验贸然修改。执行计划还受统计信息、effective_cache_size、数据相关性和查询形态影响。

调优建议

提示

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

场景 建议
OLTP 低延迟 SSD 且缓存命中率高时,1.1 可作为试验起点而非普遍真理;上线前比较代表性 EXPLAIN (ANALYZE, BUFFERS) 与尾延迟。
OLAP 不要仅因使用 SSD 就降低它;分析查询仍可能适合顺序扫描。应依据完整的扫描与索引访问组合校准,并考虑 tablespace 级设置。
小规格 若数据库通常完全驻留缓存,可考虑接近 seq_page_cost 的值;不要设得更低,并应先排除统计信息陈旧造成的错误计划。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 = 1.1 (dcs);OLAP: PG9.0–19 Beta 3 = 1.1 (dcs);CRIT: PG9.0–19 Beta 3 = 1.1 (dcs);TINY: PG9.0–19 Beta 3 = 1.1 (dcs)。 建议(待人工复核)——编辑推断(待维护者复核):1.1 用于刻画 SSD 与高缓存命中环境中随机访问更接近顺序访问的成本。

常见坑

  • 该数值是相对规划成本,不是毫秒或设备实测延迟。
  • 为修复单条查询而降低它可能伤害整体负载。
  • 基数估算错误常被误认为存储成本参数错误。
  • 低于 seq_page_cost 通常不符合物理直觉。
  • 全局值可能无法表示 SSD、HDD、网络存储混合的 tablespace。

seq_page_cost · effective_cache_size · effective_io_concurrency · default_statistics_target · enable_indexscan · enable_bitmapscan

参考资料

54 - recursive_worktable_factor

recursive_worktable_factor:设置递归查询工作表平均大小的规划器估计倍数。实测在档范围为 PG15–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 10,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置递归查询工作表平均大小的规划器估计倍数。

身份

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

生命周期

Fact
首次观测 PG15
在档版本 PG15–19 Beta 3
移除版本
引入提交 0bd7af082ace — Invent recursive_worktable_factor GUC to replace hard-wired constant.
提交日期 2022-03-24
Discussion 讨论 1

默认值变迁

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

机制详解

recursive_worktable_factor 把递归工作表的平均规模估计为非递归种子项的倍数。该估计参与工作表与其他关系连接的成本计算。

它不限制递归、内存、行数或迭代次数。低扇出的遍历可用更小值建模,高扇出的图扩展则可能需要更大估计。

该值在规划阶段使用;实际递归增长仍取决于数据与终止谓词。估计错误可能让递归项内部选择不合适的连接方法。其 user 上下文允许按会话或事务局部修改,之后执行或重新规划的工作会读取新值。

调优建议

提示

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

场景 建议
OLTP 除非代表性计划显示可重复的全负载问题,否则保留 recursive_worktable_factor 上游默认值。先测试局部覆盖,并同时计入规划延迟与执行延迟。
OLAP 分析 SQL 的连接、游标或递归规模更大,recursive_worktable_factor 的影响可能更明显。应测试完整语句族并检查估算,不要照搬一次成功的取值。
小规格 小主机上不要在无实测收益时通过 recursive_worktable_factor 增加规划搜索或内存压力。优先调整查询结构或使用限定角色设置,而不是集群级覆盖。

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG15–19 Beta 3 未修改;OLAP: PG15–19 Beta 3 未修改;CRIT: PG15–19 Beta 3 未修改;TINY: PG15–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

  • 把 recursive_worktable_factor 当作执行器资源上限,而不是规划假设或策略。
  • 只测试一组参数值或一种数据分布。
  • 期待已经缓存的计划自动重写。
  • 用全局覆盖掩盖陈旧统计信息或脆弱 SQL 结构。

work_mem · enable_nestloop · enable_hashjoin · default_statistics_target

参考资料

55 - seq_page_cost

seq_page_cost:设置规划器顺序读取磁盘页面的成本估计。实测在档范围为 PG9.0–19 Beta 3;最后在档的 PG19 Beta 3 启动默认值为 1,context 为 user。这是测试版快照事实,PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文:设置规划器顺序读取磁盘页面的成本估计。

身份

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

生命周期

Fact
首次观测 PG9.0(研究下界)
在档版本 PG9.0–19 Beta 3
移除版本
引入提交 不作断言:早于 PG9.0 研究边界
提交日期
Discussion

默认值变迁

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

机制详解

seq_page_cost 用于刻画顺序页面读取,也是规划器任意成本尺度的约定基准。它只是路径估算成本的一项,不会直接分配资源或改变执行器行为。

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

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

调优建议

提示

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

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

Pigsty 取值

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

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

Advice — 待人工复核。 当前 Pigsty 模板投影事实:OLTP: PG9.0–19 Beta 3 未修改;OLAP: PG9.0–19 Beta 3 未修改;CRIT: PG9.0–19 Beta 3 未修改;TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值,因此不推断 Pigsty 专属理由。

常见坑

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

random_page_cost · cpu_tuple_cost · effective_cache_size · enable_seqscan · effective_io_concurrency

参考资料