PostgreSQL 升级后变慢：统计信息之外的 4 个原因（JIT、并行、扩展、参数）——pg_upgrade 不搬 postgresql.conf，也不升扩展

写这篇前我列了 5 个角度：给一年前的自己的建议、常见说法哪里不对、换个定义、对企业为什么重要、用搬家类比。最后选了第二个，因为它最能直接改变升级 runbook 的顺序。

我先做了一次真实的 pg_upgrade（14.24 → 17.11，--copy 模式，374MB）：2.36 秒完成，输出最后一句是「Optimizer statistics are not transferred by pg_upgrade」，提示跑 vacuumdb --analyze-in-stages。它没提示的是另外两件事：新集群用的是 17 自己 initdb 出来的 postgresql.conf，旧集群里调过的参数一个都没带过来；扩展的 SQL 对象版本原样保留，不会自动升到新版本。

换个定义更好理解：升级后变慢 = 配置漂移，不是新版本变慢。下面每一节都先给「旧集群值 → 升级后默认值」，再给这一项在测试库上的实测影响。

要说「是配置漂移不是新版本」，先要排除新版本本身变慢。同一台机器、同一份数据、同一组参数（jit=off，并行 0，除特别说明外），每条查询 3–5 次取中位数：

也有例外：work_mem=64MB 的哈希聚合，17.11 是 2470.4ms，14.24 是 2256.5ms，17 慢 9%（下一节细说）。这组数只说明在这台测试机、这几类查询上 17.11 总体没有变慢，不代表所有查询都会更快；你的业务 SQL 仍要在升级前后各跑一遍回归。

ORDER BY d LIMIT 20 万这类大排序最直接：work_mem=4MB 时计划里是 Sort Method: external merge，Disk 149784kB；64MB 时变成内存里的 top-N heapsort，临时文件写入 0 块。14.24 上 2538.6 → 1645.5ms，17.11 上 2479.6 → 1517.6ms。换句话说，如果旧集群是 64MB，升级后不改回来，这条排序在 17 上会从 1518ms 变成 2480ms，慢 63%，而 ANALYZE 对它没有任何作用。

但我要如实写另一半：同一张表上的哈希聚合（GROUP BY 高基数列），work_mem 调大反而更慢——14.24 上 2047.0 → 2256.5ms，17.11 上 1955.5 → 2470.4ms。批次数从 129 降到 9（14）、65 降到 5（17），但 64MB 时仍然溢出磁盘。所以我的建议不是「把 work_mem 调大」，而是「把旧集群验证过的值带回来，再用自己的慢查询验证」；每个排序/哈希节点都可能用到 work_mem，并发高时总内存会成倍放大。

random_page_cost 我也测了：4 vs 1.1，在约 3%、8%、15% 三种选择率下，14 和 17 的计划全部是 Bitmap Heap Scan，没有翻转。耗时有的快有的慢（如 14.24 的 8% 区间 90.9 vs 121.3ms，17.11 同区间 88.1 vs 83.9ms），方向不一致，数据又都在缓存里，我不把它算作本次测试里的变慢原因。它仍然应该带回旧值，只是别指望它解释大部分变慢。

max_parallel_workers_per_gather 0 / 2 / 4，同一条扫描：14.24 是 185.6 / 70.7 / 44.9ms，17.11 是 167.2 / 61.2 / 38.0ms。旧集群设的是 4，升级后默认 2，17.11 上这条查询从 38.0ms 变成 61.2ms——新版本更快，但因为少了 2 个 worker，反而比升级前的 14（44.9ms）慢了 36%。这类变慢最容易被误判成「17 有性能回退」。

反过来也要看：pgbench 16 个客户端并发跑同一类查询（8 vCPU），并行 0 vs 2，14.24 是 50.2 vs 47.7 TPS，17.11 是 55.4 vs 54.7 TPS——CPU 已经被并发占满时，并行不加分甚至略降。所以判断标准是看你的慢查询是「单条大查询」还是「大量并发小查询」，而不是一律调大。

常见说法是「升级后变慢就关 JIT」。我测下来不能这么一概而论。JIT 是否触发看查询总估算成本：超过 jit_above_cost（默认 10 万）才编译，超过 50 万才做内联和优化。

40 个 CASE 的宽聚合（cost 约 156 万，触发内联和优化）：jit=on 时 14.24 从 5336.2 降到 4434.0ms，17.11 从 4768.4 降到 3935.6ms，都快了 17%，JIT 编译本身花了 214–216ms。2 表和 6 表 join（cost 14 万–43 万，只做表达式编译）：14.24 上 519.1 → 560.1ms（+8%）、2053.4 → 2124.0ms（+3%）；17.11 上 497.8 → 508.7ms（+2%）、1929.3 → 2105.0ms（+9%）。JIT 编译耗时 18–47ms；17.11 6 表 join 慢了 176ms，比编译时间本身大，说明这组 3 次中位数里也有波动。cost 7.4 万的小查询根本不触发 JIT，开关前后 192.5 vs 191.1ms。

我的处理办法：不要全局 jit=off 了事。先看 pg_stat_statements 里 jit_functions、jit_generation_time 等列（扩展升到 1.10+ 才有），找到「cost 在十几万到几十万、执行只有几百毫秒」的那类查询，它们最容易被 JIT 拖慢；要么提高 jit_above_cost，要么只对相关角色或会话 SET jit = off。旧集群如果本来就是 jit=off 且运行稳定，切换时先保持 off，升级稳定后再单独评估。

pg_upgrade 后在新集群查 pg_extension：pg_stat_statements 是 1.9，而 17 自带的默认版本是 1.11；pg_trgm 1.6、btree_gin 1.3 两边相同，不用升。执行 ALTER EXTENSION pg_stat_statements UPDATE 后变成 1.11。pg_upgrade 不会替你做这一步，扩展停在旧版本时，新版本才有的列和函数用不了。

升级扩展时要一起改监控 SQL：PostgreSQL 17 发布说明写明 pg_stat_statements 把 blk_read_time / blk_write_time 改名为 shared_blk_read_time / shared_blk_write_time。按旧列名写的 Grafana 面板或巡检脚本，在 ALTER EXTENSION 之后会直接报列不存在。

很多人会怀疑「是不是 shared_preload_libraries 里的扩展拖慢了新版本」。我用 pgbench -S（只读主键查询，scale 20，8 客户端，每轮 15 秒）在 14.24 和 17.11 上各测 6 种预加载配置，每种 3 轮。首轮单次测试时 14.24 开 pg_stat_statements 低了 20%、17.11 反而高了 7%，明显是噪声，所以又补了三轮复测。

三轮结果：pg_stat_statements 默认配置的中位数和不加载扩展相比，14.24 是 396.4k vs 391.5k tps，17.11 是 396.5k vs 398.6k tps，差距在 1% 左右；track_planning 和 auto_explain 各配置的中位数在 −15% 到 +4% 之间，但同一配置 3 轮之间最大相差约 3 成（如 14.24 只加载 auto_explain 时 303.9k–401.4k），而且不单调——17.11 上开了 log_analyze + log_timing=off 反而比只加载 auto_explain 更快。所以本次测试差异在噪声范围内，不下结论。能确定的只有一点：每条查询约 0.02ms 的只读负载下，pg_stat_statements 默认配置没有测出可见开销。

生产上我的做法不变：pg_stat_statements 保留（排查升级后变慢离不开它），auto_explain 的 log_analyze 先配 log_timing=off 和 sample_rate，在预发环境用自己的负载压一轮再上。

同一批测试实例上，我把 max_connections 设成 8、superuser_reserved_connections 设成 2 来触发连接打满：14.24 上普通角色连到第 7 个时报 remaining connection slots are reserved for non-replication superuser connections；17.11（另设 reserved_connections=2）上普通角色连 4 个后报 remaining connection slots are reserved for roles with privileges of the "pg_use_reserved_connections" role。全满时两版都是 sorry, too many clients already。

如果你的日志告警是按 14 的原文匹配的，升级后连接打满不会再触发。改成按 SQLSTATE 53300 匹配最稳，细节见 PostgreSQL 报错速查里的 sorry, too many clients already 页。

下面的 SQL 都是只读的，在旧集群和新集群各跑一次，导出后 diff。第一条把所有不是默认值的参数列出来：SELECT name, setting, unit, source FROM pg_settings WHERE source NOT IN ('default','override') ORDER BY name;。第二条看扩展：SELECT e.extname, e.extversion AS installed, a.default_version FROM pg_extension e JOIN pg_available_extensions a ON a.name = e.extname ORDER BY 1;（installed 和 default_version 不同的就是待升级）。

参数要区分「旧值是有意调过的」和「只是历史遗留」：我的做法是先原样带回，切换稳定后再逐个评估，而不是在切换当天同时改参数和升版本——两件事叠在一起，一旦变慢就分不清是谁的问题。