4 月 15 日，Bruce Momjian 发布了 PostgreSQL 19 首版 Release Notes 草案。按照统计，本次版本共包含 212 项更新。Feature Freeze 已于 4 月 8 日完成，Beta 1 预计将在下个月发布，正式版则计划于今年 9 月上线。

212 项更新，数量看起来非常惊人，但对于生产环境而言，更值得关注的是：

哪些更新，会真正影响 PostgreSQL 在生产环境中的运维与管理？

PostgreSQL 19 版本核心定位为 运维与监控优化版本，相比 PG18 的异步 I/O（AIO）以及 PG16 的 Standby Logical Replication，PG19 并没有特别突出的“明星功能”。不过，这一版本对运维、监控以及系统管理相关能力做了不少持续改进。

下面是几个比较值得关注的变化。

01 Worker 管理型异步 IO

PG18 引入异步 IO 时，使用的是静态 io_workers 配置：

• 默认值为 3
• 最大值为 32
• 需要手动调整

PG19 则改为 Worker Pool 模式，并新增了：

• io_min_workers
• io_max_workers
• io_worker_idle_timeout
• io_worker_launch_interval

新的机制可以根据负载自动扩缩容，同时回收空闲 Worker，并限制 Worker 创建速度，避免突发负载下频繁创建进程。

这一变化最大的意义在于：

异步 IO 开始更接近“默认可用”。

过去需要根据经验调整 io_workers，如今多数情况下默认配置即可运行。对于生产环境来说，这会明显降低异步 IO 的调优成本。

02 更多 LEFT JOIN 会被优化为 ANTI JOIN

PG19 对 Planner 做了一项比较实用的优化，由 Tender Wang 提交的补丁扩大了 LEFT\ JOIN\ …\ WHERE\ right_table.col\ IS\ NULL模式的优化范围，这类 SQL 现在会更容易被改写为 ANTI\ JOIN。在一些大表 JOIN 场景下，可以减少不必要的中间结果生成，从而降低执行成本。

过去经常有人讨论 LEFT JOIN … IS NULL和 NOT EXISTS哪种写法更快。PG19 之后，两种写法在更多情况下会被 Planner 统一处理。对于一些历史 SQL，升级后可能会看到执行计划发生变化。

03 pgstattuple 开始支持 Streaming Read

pgstattuple 是 PostgreSQL 中常用的诊断扩展，用于查看：

• Live Tuple
• Dead Tuple
• Free Space
• 表膨胀情况

过去它的问题是大表扫描比较慢，因为 pgstattuple 需要前台逐页读取整个表。PG19 将其接入 Streaming Read API 后，可以利用： Prefetch、 AIO、 Streaming Read等底层能力。

对于大表而言， pgstattuple 的执行成本会明显下降。这意味着过 去只能在维护窗口执行的诊断，现在更有机会在业务时间运行。

对于长期依赖 pgstattuple 或 pgstattuple_approx 做膨胀监控的环境来说，这项变化还是比较实用的。

04 编译标准从 C99 升级至 C11

PG19 将 PostgreSQL 的编译标准从 C99 正式升级为 C11。

对于普通用户来说，这项变化基本没有影响，但对于 Extension 开发者、PostgreSQL 打包维护者、企业内部构建环境则需要提前关注兼容性问题。

目前主流 Linux、macOS 以及 RHEL 8+ 都已经支持 C11。真正可能受影响的，主要还是一些较老的编译环境，以及仍然强制使用 -std=c99 的扩展项目。

如果维护 PostgreSQL Extension，建议提前检查 Makefile 与编译参数。

其余 200 多项更新，还需要关注什么？

除了前面提到的几个重点变化外，PG19 剩余的大部分更新，主要分布在几个方向。

1. 针对特定子系统的功能增强

例如 Logical Replication、Partitioning 等。这类更新不一定会影响所有用户，但对于对应场景的生产环境仍然值得关注。

1. EXPLAIN 输出变化

一些依赖 EXPLAIN 输出内容的监控工具，升级后可能会受到影响。虽然官方并不建议直接解析 EXPLAIN 文本，但实际环境中确实存在相关工具。

1. 新增 pg_stat_* 统计信息

PG19 继续增加新的 pg_stat_* 视图以及统计字段。单独来看变化不大，但长期积累下来，也是 PostgreSQL 可观测性不断增强的重要原因之一。

1. System Catalog 调整

部分直接读取系统 Catalog 的 Extension，在升级后可能需要适配。

1. 大量边缘场景修复

包括：

• 错误信息优化
• Regression Test 补充
• COPY 边缘行为修复
• 特殊数据类型组合行为调整

这些更新通常不会特别显眼，但会逐渐体现在某些过去偶尔会遇到的问题，开始越来越少出现。

对于 PG19 的 Release Notes，更适合的阅读方式其实并不是从头读到尾，而是根据自身实际使用的功能模块，重点关注对应章节。

• 使用 Logical Replication，就重点看复制相关部分
• 大量使用分区表，就重点看 Partitioning 部分
• 依赖监控与诊断工具，则更应该关注 pg stat\* 与 EXPLAIN 变化

PG19 更像一次“系统完善型”升级

整体来看，PG19 并不是一个强调“大功能”的版本。

但这一版本中 Planner 持续增强、 异步 IO 更容易管理、 诊断工具执行效率提升、 运维相关能力继续完善，这些变化，基本都集中在 PostgreSQL 日常运行过程中最常接触的部分。某种意义上，这也是一个成熟数据库版本比较典型的演进方向，不一定有特别高调的新特性，但系统整体会越来越稳定、越来越容易维护。

原文链接：

https://thebuild.com/blog/2026/05/01/two-hundred-and-twelve-things/

作者：Christophe Pettus