Postgres 19 推出内置 REPACK 功能，可在线清理表膨胀
来源标题：Postgres 19 Repack: Built-In Table Bloat Cleanup
Postgres 19 新增内置 REPACK 功能，支持在线清理表膨胀并可选按索引重排数据。测试中，100 万行表从 493 MB 降至 228 MB，缩减 54%，耗时约 9.4 秒。与需要加锁的 CLUSTER 不同，REPACK 可在不阻塞写入的情况下完成整理。
以下正文由 AI 翻译自 Hacker News 最新（原文版权归原站所有），可能存在偏差，重要内容请以原文为准。
REPACK (CONCURRENTLY, VERBOSE, ANALYZE) repack_test; INFO: repacking "public.repack_test" in physical order INFO: "public.repack_test": found 0 removable, 1000000 nonremovable row versions in 38452 pages Time: 9406.788 ms (00:09.407) Before: 493 MB → After: 228 MB (reduction of 54%) 这里有三个选项在起作用： REPACK 还可以按照索引对表的数据行进行物理重排。如果你的工作负载经常读取相关行的范围，使用 USING INDEX 进行聚簇可能会改善局部性。请在你自己的查询上测量效果；后续的更新不会自动聚簇。 对于 REPACK 功能来说，这不仅仅是清理膨胀，而是一件大事。它本身就是一项性能特性。例如，假设你有一张 orders 表，并且经常查询 WHERE created_at BETWEEN '2026-01-01' AND '2026-01-31'。如果没有物理排序，这些行可能会分散在数百个页面中。使用 REPACK orders USING INDEX idx_orders_created_at 后，这些行会按日期顺序在磁盘上连续存储，因此范围扫描会按顺序读取页面，而不是在整个表上随机 I/O。 你可能从旧版 Postgres 中了解过 CLUSTER。它做的是同样的事情，但会加锁。 REPACK (VERBOSE, ANALYZE) product_inventory USING INDEX idx_product_category; INFO: repacking "public.product_inventory" using index scan on "idx_product_category" Time: 15230.264 ms (00:15.230) Before: 618 MB → After: 320 MB (reduction of 48%, rows now ordered by category) REPACK 与 VACUUM FULL 的示例性能对比 我做了一些测试，只是为了验证它是如何工作的。对于 493 MB 的测试用例，在从原始 200 万行中删除 100 万行后还剩下 100 万行活跃数据，报告的耗时如下： 在一台资源受限的系统上进行的一次测试中，对于所述的表和测试条件，REPACK (CONCURRENTLY) 耗时 9.4 秒。结果会因表、索引、工作负载和硬件而异。 REPACK CONCURRENTLY 在实际耗时上更慢。它做了更多工作：在重建表的基础上还要进行逻辑解码和 WAL 重放。这里的权衡是花费更多时间来保持表在线。 关于 MVCC 安全性的一点说明：REPACK CONCURRENTLY 并非完全 MVCC 安全。在短暂的最终交换期间，长事务理论上可能会错过并发变更。一个在重新打包开始之前获取快照的并发事务可能会看到该表为空。这与 pg_repack 曾经具有的限制相同，并且已在 Postgres 19 的发布说明中记录。请根据你的工作负载的事务和一致性要求来评估此行为。 常规 VACUUM 和 REPACK 解决的是不同的问题：
正文由 探How 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。