跳转到主要内容

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

参考资料