PG 19 并行自动清理避坑：别被“并行”骗了，CPU 根本不是关键

PostgreSQL 19 引入了 Parallel Autovacuum（并行自动清理）。

新增 GUC 参数 autovacuum_max_parallel_workers 用于限制集群级并行 Autovacuum Worker 数量；新增表级存储参数 autovacuum_parallel_workers 用于针对单表进行配置。所有并行 Worker 仍然来自现有的 max_parallel_workers 资源池，默认处于关闭状态，该默认配置是合理的。

这是一次真正有价值的改进，但也很容易被误用。

真正实现并行化的部分是什么？

实际上，VACUUM 自 PostgreSQL 13 起就已经支持并行能力，但仅限于手工执行的 VACUUM (PARALLEL n)。到了 PostgreSQL 19，Autovacuum 终于也能够使用同一套并行机制，但需要注意并行化的只有索引清理阶段（index cleanup）。Heap Scan（扫描 Heap 构建 Dead Tuple 列表）、Heap Truncation（最后的 Heap 截断）这两个流程依然是单线程。真正发生变化的是索引阶段：当一张表存在 N 个索引时，Autovacuum 可以将这些索引分配给 N - 1 个 Worker，再加上 Leader 进程，同时进行索引清理。

这里真正关键的词，是“索引（indexes）”。

如果一张表只有：一个主键 B-tree，没有其他索引，那么 Parallel Autovacuum 实际上不会带来任何变化。因为 Leader 自己就能完成唯一索引的清理，没有额外索引可以分配给 Worker， Heap Scan 本身也不是并行的。因此不会获得性能提升，也不会明显缩短 Vacuum 时间。

真正适合 Parallel Autovacuum 的，是拥有大量或高代价索引的表，例如：

多个 B-tree
jsonb 字段上的 GIN
Partial Index
BRIN

尤其是在宽表场景中，GIN Cleanup 本身往往就是 Vacuum 的主要耗时来源。

此时一个 Worker 负责 GIN Cleanup，Leader 同时处理多个较轻量 B-tree，并行化才能真正产生收益。

因此，这个特性的本质是 Parallel Autovacuum 适用于“索引数量多”或者“索引代价高”的表。而对于绝大多数只有少量普通索引的业务表来说，并不会带来明显收益。

CPU 往往不是问题所在

很多问题恰恰从这里开始。看到 “parallel” 后，第一反应往往是“并行了，肯定更快。”随后直接在全局配置：

autovacuum_max_parallel_workers = 4

但 VACUUM 的核心瓶颈，大多数时候并不是 CPU，而是 I/O。整个过程中 Heap Scan 需要持续读取数据页；Index Cleanup 需要读取索引页；PG17 引入的 Dead Tuple TID Store 虽然位于内存，但索引页本身仍然需要从磁盘加载。如果存储系统已经在单次 Autovacuum 时跑满，再增加 3 个 Worker，并不会让磁盘 suddenly 更快，只是让更多进程排队等待同一套 I/O。

这种场景在大量云 PostgreSQL 实例中普遍存在：一个托管式 RDS 或 Cloud SQL 实例，预配置 IOPS 仅数千，对一个中等负载的 200GB 表执行清理时，已达到存储性能上限。此时开启并行，不仅无法提升总吞吐量，还会增加上下文切换开销，同时占用更多 max_parallel_workers 资源槽，影响其他查询的并行执行。

推论：并行自动清理适用于同时满足以下两个条件的环境：拥有大量索引，且存储系统能跟上负载（如预配置 NVMe、适配工作负载的 EBS gp3、本地 SSD）。仅满足其中一个条件，该特性无法发挥作用。

Worker Slot 从哪里来

很多人容易忽略另一个关键问题。
autovacuum_max_parallel_workers 虽然属于 Autovacuum 配置，但 Worker 实际来源于 max_parallel_workers，而这个资源池，本来也是查询并行使用的。这意味着如果一张高索引表的 Autovacuum 占用了 4 个 Parallel Worker，那么同一时间内，业务 SQL 的并行查询能力就会被压缩。

这一问题会因与 autovacuum_max_workers 的交互而加剧。若允许 3 个自动清理工作线程并发运行，每个线程最多配备 4 个并行工作线程，则仅清理操作就会占用 12 个工作线程槽，再加上 3 个自动清理主进程，以及任何活跃的查询并行线程，资源压力会显著增加。开启该特性前，需确保 max_parallel_workers 已配置为应对最坏情况的大小（同时需检查 max_worker_processes 参数）。

合理的配置方案

对于绝大多数集群来说，保持默认关闭，通常就是最佳选择。默认情况下，每个自动清理的并行工作线程数为 0，这一配置对于大多数无需特殊关注的表而言是最优选择。

对于特定的、拥有大量或高开销索引的大表——如包含宽 jsonb 列和 GIN 索引的表、每个分区都有多个索引的大型分区表，以及那些自动清理耗时已成为问题的表——可设置表级存储参数：

ALTER TABLE huge_jsonb_thing
    SET (autovacuum_parallel_workers = 2);

通常设置为 2 就足够。设置为 4 属于较激进的配置，需经过基准测试后再确定。设置更高的值，大概率会增加 I/O 排队开销，反而无法缩短真空清理的实际耗时。

随后，将全局参数 autovacuum_max_parallel_workers 设置为至少不小于已配置的最大表级并行工作线程数，并验证 max_parallel_workers 大小是否足以在承载正常查询负载的基础上，容纳这些并行清理线程。

如何判断它是否真正有效

在目标表执行自动清理期间，可查看 pg_stat_progress_vacuum 视图。在索引清理阶段，主进程和并行工作线程都会出现在该视图中。若工作线程快速出现并消失，而主进程在堆扫描阶段停留大部分时间，说明该表并不适合开启并行机制，应关闭该配置。

另一项诊断方法是通过 pg_stat_user_tables 或自定义监控工具，查看目标表一段时间内的总自动清理耗时。若开启并行机制后，耗时无明显变化，说明该特性未达到预期效果，其占用的资源槽可用于其他更有价值的场景。

原文链接：

https://thebuild.com/blog/2026/04/28/parallel-autovacuum/

作者：Christophe Pettus