来源：https://thebuild.com/blog/2026/05/18/postgresql-19-beta-the-four-features-youll-actually-feel/
PostgreSQL 19 Beta：你将真正感受到的四个特性
作者: 未指明
日期: 2026-05-18
PostgreSQL 19 的第一个测试版即将到来。功能冻结已于 4 月 8 日完成，PG19-Final commitfest 于 4 月 9 日关闭，发布说明草案已在 pgsql-hackers 邮件列表中。头条新闻将包括 SQL/PGQ 图查询，其他所有的预览文章也会以它们为首。但我不会。
还有另外四个 PG19 的变化，它们对运维工作的影响将比任何图查询语法都更显著。它们就在这里。
64 位 MultiXact 成员
PostgreSQL 长期以来一直存在一个与 32 位 MultiXact 成员计数器相关的"要么 vacuum，要么死"的故障模式。当一个高并发工作负载积累了足够多的共享行锁------SELECT ... FOR SHARE、外键检查，以及通常的几种情况------你可能会耗尽 40 亿的成员空间，系统将拒绝新的事务，唯一的恢复路径是在应用离线的情况下对受影响的数据库执行紧急 VACUUM。
PG19 将成员计数器扩展到 64 位。理论上，回卷问题仍然存在（到了 2^64，你会有其他问题），但实际上，这种故障模式已经消失。如果你曾经在凌晨 3 点因为多事务成员耗尽而被叫起来处理问题，这就是你关心的改变。如果没有，问问你的同事关于它的事。
并行自动清理索引工作进程
autovacuum_max_parallel_workers 允许 autovacuum 并行处理单个表上的索引，方式与手动 VACUUM (PARALLEL n) 相同。这主要是一个明显的胜利，特别是对于索引多且宽的表格，其中串行索引清理是慢速阶段。
注意与 maintenance_work_mem 的交互。每个并行工作进程都会占用自己的内存份额。在最坏的情况下，繁忙的 autovacuum 现在可能消耗 autovacuum_max_workers × autovacuum_max_parallel_workers × maintenance_work_mem 的内存。默认值是可以的。但是，那些将 maintenance_work_mem 调高到 4 GB 并配有十几个 autovacuum 工作进程的自定义调优系统，在提交升级之前应该重新计算一下。
时间序列的 FOR PORTION OF
UPDATE ... FOR PORTION OF (period) 以及匹配的 DELETE 子句终于来了。它们允许你修改其时间段内一个子范围内的时序行，PostgreSQL 会自动拆分该行，以保留两侧未触及的部分。
语义是合理的。意外之处在于触发器和外键的交互：一个 FOR PORTION OF 更新可能会在那些语句开始时并不存在的行上触发行触发器，因为该语句在执行过程中创建了它们。时间序列表上的级联 FK 行为现在比一年前更有趣（也更复杂）。在将时序逻辑投入生产之前，请务必进行测试。这个特性的规范很明确；但围绕它的应用端生态系统尚未成熟。
jit = off 成为默认值
在 PG19 中，jit 现在默认关闭。这是一个安静的改变，却会带来显著的影响。
从 PG12 开始，JIT 默认是开启的，并且相当一部分分析工作负载已经悄悄地依赖它为长时间运行的查询进行计划时代码生成。如果你运行 OLTP，你几乎肯定从未从 JIT 中受益，并且一直在为每个超过成本阈值的查询支付其规划成本。新的默认设置是正确的。
如果你运行 OLAP------而且有数量惊人的运行 PostgreSQL 的人实际上在运行 OLAP 却没有注意到------你希望在升级之前在 postgresql.conf 中显式设置 jit = on，进行基准测试，然后再做决定。升级的时机不适合去发现一个需要六分钟的报表现在需要十九分钟了。
Beta 1 是开始针对真实工作负载测试这些特性的时机。上面这四个特性改变了数据库在生产环境中的实际运行感受，而不仅仅是在幻灯片上展示它所能做的事情。