PG 19 终于把并行 VACUUM “计划了几个、拉起几个”说清楚了
digoal约 9 分钟本期播客
PG 19 终于把并行 VACUUM “计划了几个、真正拉起几个”说清楚了
最可怕的运维问题，不是系统慢。
而是系统慢了，你连它到底有没有按预期并行起来，都看不见。
2026 年 3 月 19 日，PostgreSQL 提交了一个乍看很“小”，但对 DBA、架构师、应用开发者都非常现实的补丁：
adcdbe93860b16a069c6834062e56e731c54a1a1
标题是：Add parallel vacuum worker usage to VACUUM (VERBOSE) and autovacuum logs
很多人一看会说：
“不就是多打两行日志吗？”
如果你真这么看，这篇文章你最好认真读完。
因为这次改动真正补上的，不是格式美化，而是 PostgreSQL 在自动维护这件事上，一个长期被低估的硬伤：
可观测性断层。
我先给结论：
这不是一个“性能补丁”，却可能比某些性能补丁更重要。因为它修的不是速度，而是 DBA 对系统行为的判断能力。
一、为什么这件事重要？因为运维里最贵的，不是慢，而是“慢得不透明”
先把背景讲清楚。
PostgreSQL 官方文档对 VACUUM 说得很直白：
常规 VACUUM 是必须的，否则 dead tuples 会堆积，空间回收、可见性、索引健康都会出问题；同时，VACUUM 又会带来显著 I/O 流量，可能影响其他活跃会话。
换句话说，VACUUM 从来不是“后台打扫卫生”这么简单。
它本质上是：
性能维护 空间治理 XID 生命周期管理 系统稳定性保障
所以 VACUUM 的关键，不只是“有没有跑”，还包括：
跑得够不够及时 跑得够不够快 有没有吃到并行能力 为什么没吃到
问题就在这里。
PostgreSQL 早就支持手工 VACUUM (PARALLEL ...)，而且官方文档明确说明：
并行只发生在 index vacuum 和 index cleanup 阶段 实际 worker 数受 PARALLEL参数、max_parallel_maintenance_workers、可并行索引数量、min_parallel_index_scan_size等限制文档还特别强调：指定了多少，不保证真的能用到多少，甚至可能一个也拉不起来
注意这句话的含义。
它意味着在真实生产里，存在一个非常关键的差距：
planned workers ≠ launched workers
而过去，恰恰是这个差距，在日志层面并不透明。
二、这次补丁到底改了什么？说白了，就是把“想并行”和“真并行”都记账了
这次 commit 做的事其实非常具体：
它把下面两件事，加入到了：
VACUUM (VERBOSE)输出autovacuum 日志
这两件事就是：
计划使用多少个 parallel workers 实际成功拉起多少个 parallel workers
这看似只是多打印两个数字，
但对生产运维来说，它补的是一条因果链。
以前你看到某张大表 vacuum 慢，常见推理路径是这样的：
表大 索引多 vacuum 很慢 应该是系统忙，或者参数不够，或者 autovacuum 不行
这套推理有个致命问题：
中间少了一层关键事实。
你不知道：
这次 vacuum 原本计划并行几个 最后实际只拉起了几个 是根本不满足并行条件 还是满足条件但 worker 没抢到 是参数压制了并行 还是系统资源竞争导致启动失败
这就是典型的 observability gap。
系统不是没有状态，而是状态没有进你最依赖的运维渠道。
三、为什么 DBA 应该高度重视？因为 autovacuum 本来就是“看不见的关键工人”
这次补丁最值得强调的一点，其实不是 VACUUM (VERBOSE)，而是 autovacuum logs。
commit message 明确写了：
过去这类信息只在 VACUUM (VERBOSE)期间以INFO消息出现所以实际上并不会进入 autovacuum 日志 虽然当前 autovacuum 还不支持 parallel vacuum 但后续 patch 会启用它，并将这些日志用于回归测试
这段话的信息量非常大。
第一层意思：社区已经在为“parallel autovacuum”铺路
截至 2026 年 3 月 22 日，这个 commit 本身并没有让 autovacuum 立即并行化。
这一点必须说死，不能偷换概念。
但它已经把日志先补上了。
为什么？
因为社区后续 patch 正在推进 autovacuum 并行处理索引。CommitFest 页面显示相关 patch 系列仍处于 PG19-Final 周期的审阅流程中。
这说明什么？
说明 PostgreSQL 社区不是临时起意加几行日志，
而是在为下一阶段的自动维护并行化，先补监控闭环。
第二层意思：自动化系统最怕“无人值守 + 无法解释”
手工 VACUUM (VERBOSE) 你至少还能盯着看。
autovacuum 呢？
它是无人值守的。
它出问题时，你能依赖的往往只有：
服务器日志 log_autovacuum_min_durationpg_stat_progress_vacuum一些外部监控
如果日志里没有 planned/launched 这层信息，那么很多现场分析其实是靠猜。
这在生产里代价非常高。
四、第一性原理：为什么“多两项日志”会是大事？
因为运维调优本质上不是魔法，而是闭环控制。
第一性原理 1：你无法优化一个看不清的系统
并行 VACUUM 的真实效果，取决于多个条件同时成立：
表上有足够多、且支持并行 VACUUM 的索引 索引大小超过 min_parallel_index_scan_sizePARALLEL参数没有把上限卡死max_parallel_maintenance_workers没有太低系统当时确实能拉起 worker 成本延迟和资源争用没有把收益吞掉
这是一个典型的“多条件门控系统”。
在这种系统里，单看结果不够。
你必须知道每个门到底开没开。
而 planned/launched workers，就是其中最核心的一个门。
第一性原理 2：自动维护的价值，不在于“自动”，而在于“自动得可验证”
很多团队把 autovacuum 想得太浪漫：
开着就行，它会自己搞定。
这是危险的。
真正成熟的自动化，不是“系统替你做事”，
而是“系统做了什么、没做到什么，你都能验证”。
所以这次补丁最深的价值不是技术细节，而是哲学转向：
PostgreSQL 在把 VACUUM 从“你最好相信它在工作”，推进到“你可以更精确地核对它怎么工作”。
五、对 DBA 和架构师，这件事改变了什么判断？
1. 以后看到 vacuum 慢，先别急着怪参数
以前很多团队遇到 vacuum 慢，默认动作是：
调大 max_parallel_maintenance_workers调大 maintenance_work_mem降 autovacuum_vacuum_cost_delay手工跑一次 VACUUM (VERBOSE, PARALLEL ...)
这些动作不一定错。
但少了 planned/launched 的日志信息，很多调参其实接近盲调。
这次补丁之后，一个更专业的排查顺序应该是：
这次 vacuum 计划并行几个？ 实际拉起了几个？ 表上有多少索引真正满足并行条件？ 是参数上限问题，还是 worker 资源问题？ 如果 launched 明显低于 planned，瓶颈到底在谁？
从“凭经验猜”转向“用证据拆因果链” ，这是 DBA 成熟度升级，不是日志美化。
2. 以后评估 autovacuum，不该只看“有没有跑”，还要看“跑得像不像你以为的那样”
这点非常关键。
很多团队看 autovacuum，只盯：
频率 时长 是否阻塞 是否触发 wraparound
但随着并行能力进入自动维护路径，
今后一个更关键的问题会变成：
autovacuum 是否真的利用了你给它预留的并行资源？
如果没有，那资源配得再漂亮，也只是配置文件里的理想主义。
六、对应用开发者，这和你也有关，不只是 DBA 的事
很多开发者会想：
“autovacuum、parallel worker 这些，不是 DBA 关心的吗？”
错。
因为最终承担代价的，是应用延迟、吞吐和发布窗口。
如果 vacuum 跑不顺，会发生什么？
表和索引膨胀 扫描成本变高 缓存效率变差 更新/删除链路更重 XID 风险逼近 业务低峰维护窗口被拉长
而并行 VACUUM 能不能真正起效，决定的是这些问题恶化得快还是慢。
所以这次补丁对开发者的意义，不是让你去研究日志字段，
而是提醒你：
数据库维护能力是否透明，最终会反馈到你应用的性能稳定性和上线节奏。
尤其是那些：
大表 多索引 高频 UPDATE / DELETE 长事务较多 表膨胀容易积累
的业务系统，更不该把这事当“后厨问题”。
七、但要讲清楚边界：这不是性能奇迹，也不是“日志越多越先进”
这篇文章如果只写到这里，就会变成鸡血文。
所以边界必须讲清楚。
边界 1：这次补丁本身不让 VACUUM 更快
这是可观测性增强，不是直接执行加速。
它让你更容易知道并行到底有没有发生，但它本身不增加 worker，不缩短 I/O，不减少 dead tuples。
所以别把它吹成“VACUUM 提速补丁”。
边界 2：如果你的表根本不适合 parallel vacuum，这些日志价值有限
官方文档说得很明确：
只有支持 parallel vacuum 的索引方法才行 索引大小得超过 min_parallel_index_scan_size只有当可并行索引足够时才有 worker 意义 一个索引最多由一个 worker 处理 索引太少时，根本没法并行出像样收益
如果你的表：
索引少 索引小 更新不重 autovacuum 本来就很轻松
那这次日志增强对你帮助有限。
此时正确观点就不是“终于能救命了”，而是：
这补丁对我不是核心收益，但它对复杂维护场景是基础设施。
边界 3：如果你的核心问题是长事务、锁冲突、成本延迟配置错误，这补丁不会替你兜底
并行 worker 拉不起来，很多时候不是 vacuum 逻辑差，而是系统现实差：
worker 资源争抢 长事务拖住回收 锁冲突导致 autovacuum 效果打折 cost delay 太保守 I/O 饱和让并行意义下降
也就是说：
日志能帮你更快确认问题，不会自动帮你解决问题。
八、如果前提崩塌，观点要怎么改？
这正是专业分析和流量文章的分水岭。
前提成立时
如果你的系统满足这些前提：
大表、多索引 并行 VACUUM 有现实收益空间 你依赖 autovacuum 持续维持健康 你经常需要解释 vacuum 行为与实际效果差异
那我的观点很明确：
这次补丁非常值钱。因为它把“并行维护是否真的发生”从隐性状态变成了显性证据。
前提崩塌时
如果你的系统是：
小规模业务 表不大、索引不多 很少碰到 vacuum 成为瓶颈 很少分析 autovacuum 日志
那这次补丁的重要性就应该下调。
这时更合理的观点是：
它不是立刻带来收益的功能，而是 PostgreSQL 为更复杂自动维护时代提前铺的观测底座。
这不是自相矛盾。
这是把功能价值放回场景里判断。
九、这件事真正透露了 PostgreSQL 的什么方向？
我认为它透露了一个非常重要的趋势：
PostgreSQL 社区正在把“自动维护可观测性”当成一等公民，而不是顺手补日志。
最近一段时间，你会发现 PostgreSQL 在 VACUUM 相关能力上持续加码：
pg_stat_progress_vacuum持续增强2025 年 12 月新增了 mode和started_by列，区分normal/aggressive/failsafe与manual/autovacuum/autovacuum_wraparound现在又把 parallel vacuum 的 planned/launched 信息写进 VACUUM (VERBOSE)和 autovacuum logs后续 patch 还在推进 autovacuum 的并行索引处理
这些动作放在一起看，信号就很清楚：
PostgreSQL 不是只想让 VACUUM 能跑，而是想让 VACUUM 更可解释、更可验证、更可运营。
这比单纯“再快一点”更像成熟数据库该走的路。
结论
这次 Add parallel vacuum worker usage to VACUUM (VERBOSE) and autovacuum logs，表面上只是多了两项日志。
但本质上，它修的是 PostgreSQL 自动维护体系里一个非常真实的问题：
并行能力存在，但运维证据不完整。
对 DBA 来说，这意味着以后分析 VACUUM 慢，不必再靠猜。
对架构师来说，这意味着自动维护从“黑箱后台任务”进一步变成“可运营的系统行为”。
对开发者来说，这意味着数据库性能稳定性背后，又少了一块“出了问题但说不清”的灰区。
所以，这个补丁最值得记住的一句话是：
数据库真正成熟，不是功能越来越多，而是关键后台行为越来越能被验证。
你怎么看
你们线上在分析 VACUUM / autovacuum 问题时，最痛的到底是“慢”，还是“慢得没证据、慢得不好解释”？
如果后续 parallel autovacuum 真进主干，你更关心它带来的性能收益，还是先把日志、进度、监控补齐？
评论区聊聊：在数据库维护这件事上，你更缺“更强能力”，还是“更强可观测性”？