每个 Postgres 版本都有其个性。有些版本侧重于一个重要的特性。有些则在解决一个长期存在的痛点。有些版本则充满了那些“哦，不错”的改进，直到你升级后你才会完全意识到，它让你的日常工作流程变得稍微顺滑了一些。当然，几乎每个版本也都会在某些方面提供性能改进。Postgres 19 就感觉像是一个兼具所有这些元素的版本。REPACK CONCURRENTLY 是对大型生产数据库的一项重要的生活质量提升，它是内置的。是的，这个版本还有一些重要的功能。SQL 属性图查询将会受到很多关注。逻辑复制也在不断完善。此外，在 VACUUM、EXPLAIN、COPY、分区、监控、性能和规划器行为等领域的不懈改进，继续使 Postgres 变得更好，不是在华丽的方式下，而是在非常实用的“这帮助我运行业务系统”的角度上。如同往常的 beta 版本，细节可能在 GA 之前发生变化。但现阶段 Postgres 19 的 beta 版本已经发布，现在正是开始关注即将到来的版本的好时机，更重要的是，它对那些在 Postgres 上构建和运营的人意味着什么。REPACK 随时可用 如果你操作 Postgres 的时间足够长，你可能会经历过这样一个时刻：你想要回收表的膨胀，重写一个表或重新组织数据 — 但你真的不想因为 VACUUM FULL 或 CLUSTER 而带来的锁而受挫。围绕这个问题早已存在一个扩展生态，最显著的就是 pg_repack。仅此一点就可以说明一些事情：用户确实有这样一个真实的需求，而这个生态系统填补了这个空白。Postgres 19 将一个新的 REPACK 命令带入核心，支持 REPACK CONCURRENTLY。我预计 REPACK CONCURRENTLY 将成为生产 Postgres 用户比一般发布说明阅读者更关心的特性之一。分区变得更加实用 多年来，Postgres 的分区功能有了很大改善。它从“你可以这么做，但你可能需要理解很多内部机制和细节”变成了更加易于接触的功能。Postgres 19 在这一工作基础上继续向前发展，支持合并和拆分分区。这听起来简单，但解决了一个真实的操作问题。分区策略是你常常在信息不完全的情况下选择的事情。你最初选择一个在当时看起来合理的分区方案。然后你的工作负载发生变化。你的保留窗口发生变化。你的数据量增长得比预期快。或者几个分区变得异乎寻常的大，而其他的又非常小。能够拆分和合并分区为你提供了更多空间，让你的设计能够随着时间的推移而演变。-- 将 Q1 和 Q2 合并为一个分区 ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1; -- 将 Q3 分区拆分为按月的时间间隔 ALTER TABLE customer_orders SPLIT PARTITION orders_2026_q3 INTO ( PARTITION orders_2026_07 FOR VALUES FROM ('2026-07-01') TO ('2026-08-01'), PARTITION orders_2026_08 FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'), PARTITION orders_2026_09 FOR VALUES FROM ('2026-09-01') TO ('2026-10-01') ); 像这样的功能很重要，因为最佳的数据库设计很少是静态的。良好的系统是不断发展的。Postgres 提供了更多的调整方式，而不需要从头开始重建，这正是使 Postgres 持久运行所需的渐进式改进。逻辑复制继续成熟 逻辑复制是 Postgres 开发中过去几个版本最重要的领域之一。它对于迁移、升级、报告系统、数据移动、选择性复制以及越来越多的高可用性和操作工作流程都非常有用。Postgres 19 在逻辑复制方面继续取得一些重要的进展。最大的改进是：序列值现在可以同步，以便订阅者更好地匹配发布者。任何与依赖于序列的应用程序表进行逻辑复制的人都知道这是为什么重要。没有序列状态的数据复制可能会给你带来尴尬的过渡后问题。数据已经移动，但下一个生成的 ID 可能不是你需要的地方。Postgres 19 还为出版物添加了 ALL SEQUENCES 支持，序列同步错误报告以及更好的订阅刷新行为。这是另一项不错的改进：出版物可以使用 EXCEPT 子句来排除某些表。这样更符合人们实际操作系统的方式。你通常想要的是“基本上所有内容，除了这几个东西。”让这一点更简单是件好事。此外，当需要时，wal_level = replica 可以自动启用逻辑复制，并引入新的 effective_wal_level 来报告实际发生的情况。这是另一个实用的改进：减少配置陷阱，并在 Postgres 执行某些操作时提供更好的可视性。