PostgreSQL 19增加了REPACK命令，用重写表的方式处理膨胀、腾出磁盘空间，也支持按索引调整数据顺序。使用REPACK (CONCURRENTLY)时，大部分重写工作可以与业务读写同时进行，减少大表维护对停机时间的要求。

常说的“不锁表”并不准确：并发模式也会使用锁，最后替换文件时仍需短暂强锁。普通REPACK没有CONCURRENTLY选项时，则会在整个过程中挡住其他会话访问目标表，执行前一定要分清。

一、表膨胀为什么需要重写？

例如历史订单表曾占100GB，删除大批旧订单后只剩一小部分有效记录，文件也不会马上缩小。数据库既要照顾仍在读取旧数据的事务，也会优先把清理出来的空间留给本表以后使用。

普通 VACUUM 的价值，是清理不再需要的旧版本，让空间可重复使用，并维护可见性等信息。它通常不会把整张表压缩成一个紧凑的新文件。REPACK 则把有效内容搬到新文件，再重建相关索引，适合处理“表以后也不会再长回这么大，需要让这部分磁盘真正腾出来”的情况。

因此，不要看到文件大就立刻 REPACK。持续增长、会很快重新用到空闲空间的表，保留可复用空间可能更划算。首先要分清：这是正常预留、清理跟不上，还是一次大规模删除留下的持久膨胀。

二、为什么减少阻塞比单纯快几分钟更重要？

维护一张核心订单表时，长时间只允许维护进程访问这张表，可能同时堵住查询、下单和更新。请求还在不断进来，程序能用的数据库连接被占满，影响就会扩散到其他页面。

并发重写的意义，在于把大量复制和索引构建工作放到允许正常读写的阶段完成，让真正需要排他访问的文件切换阶段缩短。这使部分过去只能安排停机的大表维护，有机会放进业务低峰窗口。

但允许读写，不代表完全不影响业务。复制数据、重建索引、处理这段时间新增的修改，都要读写磁盘，也会消耗 CPU、内存和额外空间。读写没有被锁直接挡住，也可能因为磁盘繁忙而变慢，所以仍要观察业务延迟。

三、三种维护方式怎么选？

REPACK 也不能代替 autovacuum。事务 ID 冻结、日常旧版本清理应继续由 VACUUM 体系承担。重写一整张表通常比日常清理成本高得多。

四、使用前先检查什么？

先确认目标版本、维护权限和表类型。并发重写需要普通有日志的 heap 表，以及主键或基于索引的复制标识；无日志表、物化视图等不适用同样的并发方式。分区父表不能直接使用这一并发选项，需要评估具体叶子分区。

再确认磁盘余量。重写期间新旧表及索引会同时存在；若还需要排序、处理大量并发变更，额外用量会继续增加。不能只按“预计回收多少空间”计算维护前所需空间。

最后排查长事务、无效索引和同时进行的表结构变更。它们可能让维护一直等待、执行失败，或消耗更多资源。还有一个限制：某些在重写开始前就取得旧数据快照的事务，在文件切换后可能看不到表里的记录。会运行长时间报表的系统，应先测试这种情况。

五、最小使用方式与观察方法

以下示例中的 public.orders应替换成经过评估的目标表。先在测试库执行，不要直接对生产大表尝试：

REPACK (CONCURRENTLY, VERBOSE) public.orders;

命令应在独立会话中执行，不要放进 BEGIN/COMMIT 事务块。完成后更新统计信息，再观察典型查询：

ANALYZE public.orders;

维护运行时，可以另开连接检查当前进度，以及是否有会话正在等待：

SELECT * FROM pg_stat_progress_repack;SELECT pid, state, wait_event_type, wait_event, pg_blocking_pids(pid) AS blockersFROM pg_stat_activityWHERE query ILIKE '%REPACK%' AND pid <> pg_backend_pid();

结果不能只记录腾出了多少空间，还应比较表和索引大小、整个维护用时、业务延迟、最高磁盘用量及复制落后程度。若回收空间伴随持续的业务抖动，就要重新选择对象或安排时间。

REPACK让表重写多了一种选择。并发模式减少需要挡住读写的时间，却不会免除文件切换和资源成本。先确认表的条件与业务能承受的影响，才能决定是否采用。