Manisankar Kanagasabapathy：在PostgreSQL中使用pg_repack在线重建表
内容提要
本文介绍了在PostgreSQL中重建表的方法，包括使用VACUUM FULL命令的限制，Oracle中使用DBMS_REDEFINITION包的手动步骤，以及PostgreSQL中的pg_repack扩展。pg_repack可以在不中断读写操作的情况下重建表，并有效去除碎片。使用pg_repack重建表简单且提高数据库性能和存储利用率。
延伸解读
pg_repack 与 VACUUM FULL 的锁机制对比
VACUUM FULL 在重建表期间会持有 ACCESS EXCLUSIVE 锁，完全阻塞读写操作，因此不适合生产环境。而 pg_repack 仅在初始设置和最终交换阶段短暂持有 ACCESS EXCLUSIVE 锁，大部分时间只持有 ACCESS SHARE 锁，允许并发读写。这种锁机制的差异是 pg_repack 能实现在线重建的关键，也是它比 VACUUM FULL 更适合高流量场景的原因。
pg_repack 与 Oracle DBMS_REDEFINITION 的操作
Oracle 的 DBMS_REDEFINITION 需要手动执行六个步骤：验证、创建中间表、启动重定义、复制依赖、同步增量、完成交换。而 pg_repack 将这些步骤封装为一条命令，大大简化了操作。对于从 Oracle 迁移到 PostgreSQL 的团队，pg_repack 降低了在线重建表的学习和运维成本，但需注意其前提条件，如主键或唯一索引。
生产环境使用 pg_repack 的关键参数与风险控制
在生产环境中，应关注 --wait-timeout 和 --no-kill-backend 参数。默认情况下，若在 60 秒内无法获取锁，pg_repack 会强制取消冲突查询，可能影响用户业务。建议设置较高的 --wait-timeout 并启用 --no-kill-backend，让 pg_repack 在无法获取锁时跳过该表，避免干扰正常查询。此外，--jobs 可并行构建索引，但仅适用于全表重建。
pg_repack 的适用条件与限制
pg_repack 要求目标表必须有主键或非空唯一索引，且不支持 PostgreSQL 系统目录表。执行完整重建需要约两倍于表及其索引的磁盘空间。仅表所有者和超级用户可以使用。这些限制意味着并非所有表都适合用 pg_repack 在线重建，需提前评估表结构和资源。
Q&A
在PostgreSQL中，为什么需要重建表？
重建表可以去除碎片，优化数据库性能，特别是在大量删除操作后，表内会产生碎片，导致性能瓶颈。
pg_repack与VACUUM FULL有什么区别？
pg_repack可以在线重建表，允许并发读写操作，而VACUUM FULL在重建期间会锁定表，影响读写操作。
如何在PostgreSQL中安装pg_repack扩展？
可以通过包管理器或源代码安装，安装后需在数据库中创建扩展，使用命令 'CREATE EXTENSION pg_repack'。
pg_repack的重建过程包括哪些步骤？
重建过程包括创建日志表、添加触发器、创建新表、构建索引和应用更改。
使用pg_repack重建表时需要注意哪些参数？
重要参数包括控制锁定行为的–wait-timeout和–no-kill-backend选项，以避免影响用户查询。
pg_repack支持哪些PostgreSQL版本？
pg_repack支持PostgreSQL 9.5及以上版本。
