两种命令都能通过重写表腾出空间。比较REPACK (CONCURRENTLY)与VACUUM FULL时，还应看维护中的正常读写能否继续，以及额外资源用了多少，而不只是看最终文件大小。

这套实验在测试库中完成，包含准备数据、删除记录、维护和记录结果。没有预设速度或回收比例，不同硬件负载下应填写自己的实际测量。

一、先准备两张相同的测试表

请使用独立的19测试库。下面以约20万行为例，可按设备容量调整，但不要直接把对象换成业务生产表：

CREATE TABLE public.demo_full ( id bigint PRIMARY KEY, payload text NOT NULL);INSERT INTO public.demo_fullSELECT g, repeat(md5(g::text), 8)FROM generate_series(1, 200000) AS g;CREATE TABLE public.demo_repack (LIKE public.demo_full INCLUDING ALL);INSERT INTO public.demo_repackSELECT * FROM public.demo_full;DELETE FROM public.demo_full WHERE id % 5 <> 0;DELETE FROM public.demo_repack WHERE id % 5 <> 0;ANALYZE public.demo_full;ANALYZE public.demo_repack;

两张表都留下五分之一记录。这里的主键也用于满足并发重写的相关条件。实验前确认没有无效索引，并留出新旧表与索引同时存在的磁盘空间。

二、先记下大小，别凭感觉比较

SELECT relname, pg_size_pretty(pg_relation_size(oid)) AS heap_size, pg_size_pretty(pg_indexes_size(oid)) AS indexes_size, pg_size_pretty(pg_total_relation_size(oid)) AS total_sizeFROM pg_classWHERE oid IN ('public.demo_full'::regclass, 'public.demo_repack'::regclass);

表主体、索引和总大小要分开记录。n_dead_tup 是估计值，不能直接当作精确膨胀比例。普通 VACUUM 也可能先完成部分清理，但通常不会像完整重写那样把表压成紧凑文件。

三、分别执行维护，记录真实耗时

使用 psql 时可打开计时。下面每条维护命令独立执行，不要包在 BEGIN/COMMIT 中：

timing onVACUUM (FULL, ANALYZE, VERBOSE) public.demo_full;REPACK (CONCURRENTLY, VERBOSE) public.demo_repack;ANALYZE public.demo_repack;

执行完成后，再运行一次大小查询，并核对两张表的记录数和关键数据。比较总维护时间时，两边都要计入统计信息更新等必要收尾。

先跑的操作可能面对较冷的缓存，后跑的操作可能已经受益于预热。要比较速度，应重新准备相同数据、交换执行顺序并重复几轮，不能只凭一次结果排名。

四、另开连接，观察读写会不会被挡住

在维护进行期间，从另一个连接对对应表做短查询。测试连接设置有限等待时间，避免一直卡住：

SET statement_timeout = '2s';SELECT count(*) FROM public.demo_full;SELECT count(*) FROM public.demo_repack;

还可以在单独一轮实验中，反复更新两张表中存在的一行，观察响应时间。写入实验会改变表状态，应先重新准备相同数据，不能再与此前空闲负载的结果混比。

VACUUM FULL 在重写期间需要排他访问；并发 REPACK 的主要阶段允许读写，最后切换仍需要短暂强锁。小表可能转眼就执行完，没有观察到阻塞，不等于完全不加锁。

五、结果表应该记录哪些内容？

并发REPACK还要处理执行期间发生的写入，完整用时可能更长，换来的是较少阻塞。在线系统应结合业务连续性，而非只比较结束时间。

六、从实验结果回到生产选择

表不大且允许停机时，VACUUM FULL可能更简单。需要维持读写又要回收空间时，可评估并发REPACK，同时核查主键或复制标识、长事务、空间和权限。

还需单独测试旧快照可见性对长报表的影响。生产选择应综合空间收益、请求延迟和复制恢复时间，不宜用单条命令的作结论。