空表执行Vacuum耗时3秒排查：系统与本地性能差异及分区影响分析

根本原因确认 #

是的，大量表分区（36万+普通表）是核心问题：
PostgreSQL执行VACUUM时，首先需要从pg_class等系统表中查询目标表的元数据。当pg_class条目达到近200万时，系统表的查询效率会急剧下降——即使是查询单个空表的元数据，也需要在海量条目中遍历或索引查找，导致耗时剧增。
同时，autovacuum需要定期遍历所有表（包括所有分区）来判断是否需要执行VACUUM，数百万级的表数量会让这个遍历过程极慢，进而引发整体autovacuum卡顿。

另外，你提到pg_stat_progress_vacuum中看不到卡顿的VACUUM，原因是：空表VACUUM的耗时主要集中在元数据查询与锁等待阶段，还未进入实际的数据扫描、冻结等核心VACUUM流程，而该视图仅跟踪VACUUM的核心执行阶段，所以无法捕获到这部分耗时。

定位问题的具体方法 #

• 查看VACUUM的等待事件：执行VACUUM t;的同时，在另一个会话中查询：

  SELECT pid, wait_event_type, wait_event, query FROM pg_stat_activity WHERE query LIKE '%VACUUM t%';
  

  如果wait_event显示为relation且关联pg_class，则确认是系统表查询或锁竞争导致的卡顿。
• 测试系统表查询性能：直接执行查询目标表元数据的语句，对比本地与生产环境耗时：

  SELECT relfilenode, reltablespace FROM pg_class WHERE relname = 't' AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public');
  

  若生产环境该查询耗时远超本地，说明pg_class存在性能瓶颈。
• 检查autovacuum状态：查询autovacuum的执行记录，看是否有大量分区任务在排队：

  SELECT relname, last_autovacuum, vacuum_count FROM pg_stat_autovacuum ORDER BY last_autovacuum DESC;
  

修复措施 #

1. 优化系统表性能 #

大量分区的创建/删除会导致pg_class等系统表产生碎片，降低查询效率。在业务低峰期执行：

VACUUM FULL pg_class;
ANALYZE pg_class;

VACUUM FULL会重建系统表，消除碎片；ANALYZE更新统计信息，让查询优化器生成更优计划。

2. 针对分区表优化autovacuum配置 #

• 对全冻结或空分区禁用autovacuum：

  ALTER TABLE your_partition SET (autovacuum_enabled = false);
  

  可以批量处理符合条件的分区：

  DO $$
  DECLARE
      rec RECORD;
  BEGIN
      FOR rec IN SELECT relname FROM pg_class WHERE relkind = 'r' AND relname LIKE 'your_partition_prefix_%'
      LOOP
          EXECUTE 'ALTER TABLE ' || quote_ident(rec.relname) || ' SET (autovacuum_enabled = false);';
      END LOOP;
  END $$;
  

• 调整autovacuum全局参数：
  • 适当提高autovacuum_max_workers（如从默认3调整为8），增加并行处理能力，但需注意系统CPU/IO负载。
  • 调大autovacuum_naptime（如从默认1分钟调整为5分钟），减少autovacuum遍历所有表的频率。

3. 清理无用分区 #

如果99.9%的分区为全冻结或空状态，可归档数据后删除这些分区，从根本上减少系统表的条目数量，提升整体元数据查询效率。

4. 升级PostgreSQL版本 #

PostgreSQL 12及以上版本对分区表的元数据管理、VACUUM性能有显著优化，尤其是在处理大量分区时的系统表查询效率提升，可考虑升级到较新版本。

内容的提问来源于stack exchange，提问作者Peter