第三期：PG 19 新特性全景解读

从原生图查询到执行计划“锁死”，2026年最值得关注的数据库版本来了

2026年4月8日，PostgreSQL 19正式进入特性冻结阶段，意味着所有新功能已锁定，后续开发重心全面转向稳定化测试与Bug修复。目标发布时间为2026年9月，Beta测试预计于5月启动。随着Bruce Momjian完成PG 19发布说明的首个草稿，这个年度重磅版本的全貌正逐渐清晰。

PG 19延续了PG社区“插件验证→内核化收敛”的演进路径，多个曾在扩展生态中充分验证的能力正式进入内核——SQL/PGQ图查询、原生REPACK表重整、执行计划锁定等重磅功能同时落地，标志着PostgreSQL在“多模数据平台”的战略方向上迈出了关键一步。

一、SQL/PGQ图查询：关系型数据库的“图思维”革命

1.1 从扩展到内核：图查询的“毕业”时刻

PG 19最受瞩目的新特性，无疑是SQL/PGQ属性图查询的原生支持。此前，在PostgreSQL中实现图查询主要依赖Apache AGE扩展、AgensGraph分支或pgRouting算法库。PG 19将图查询能力直接纳入内核，用户无需安装任何扩展，即可使用标准SQL语法在PostgreSQL内部执行属性图查询。

SQL:2023标准引入了SQL/PGQ，首次允许关系型数据库将图遍历视为一等公民的声明式操作。PG 19对这一标准的落地，不仅是语法层面的支持，更是PostgreSQL从关系型数据库向多模数据平台演进的重要里程碑。

1.2 实际应用场景：知识图谱与社交网络

图查询的核心价值在于表达实体之间复杂的关联关系。一个典型的场景是知识图谱——如“查找A的关联人员中，谁与B有过直接交易”这类多层关联查询，在传统SQL中需要复杂的自连接与递归CTE，在图查询中则可以用一条清晰的路径表达式完成。社交网络关系分析、推荐系统的协同过滤、欺诈检测中的资金链路追踪等场景，都能从中直接受益。

1.3 与向量检索形成“语义+关系”双轮驱动

结合上一期讨论的pgvector向量检索能力，PG 19的图查询进一步丰富了数据库的表达范式。向量检索擅长“模糊语义匹配”（如“找出与这张图片相似的图片”），图查询擅长“精确关系遍历”（如“找出这张图片的所有上传用户的好友关系”）。两者结合，PostgreSQL在多模数据场景下的覆盖广度达到了前所未有的水平。

二、pg_plan_advice：执行计划的“终极掌控”

2.1 DBA的噩梦：执行计划突然跑偏

一条长期稳定运行的核心SQL，可能因为统计信息更新、数据库版本升级、配置参数调整，突然被查询规划器选择了错误的执行计划，导致性能从毫秒级暴跌至秒级甚至分钟级。此前，DBA只能通过第三方插件pg_hint_plan、重写SQL或调整全局参数来临时解决，不仅门槛高、兼容性风险大，还缺乏官方原生的稳定支持。

2.2 路径生成策略：扩展规划器的底层钩子

PG 19引入的路径生成策略（Path Generation Strategies）机制，为插件提供了在查询规划器最早阶段影响决策的能力。传统规划器的工作流程是先产生多条路径（如顺序扫描、索引扫描、Hash连接等），再通过成本比较淘汰劣质路径。但由于规划器可能在成本比较早期就丢弃一些路径，扩展插件在旧框架下很难强制保留特定计划。路径生成策略机制解决了这一根本性问题，使插件能够在内核层面稳定地影响规划决策。

2.3 pg_plan_advice使用方法

pg_plan_advice作为contrib模块随PG 19一同发布，提供原生的执行计划锁定能力。核心使用流程如下：

第一步：获取计划建议字符串

EXPLAIN (COSTS OFF, PLAN_ADVICE) 
SELECT * FROM join_fact f JOIN join_dim d ON f.dim_id = d.id;

系统会返回类似如下的建议字符串：

JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d)

其中：JOIN_ORDER(f d)指定以f表为驱动表、d表为关联表；HASH_JOIN(d)指定d表作为哈希连接的内表；SEQ_SCAN(f d)指定对两表均使用顺序扫描；NO_GATHER(f d)指定不将两表置于并行Gather节点之下。

第二步：应用计划建议

通过GUC参数将建议字符串应用到后续查询中：

SET pg_plan_advice.advice = 'JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d)';

用户还可以编辑建议字符串，仅保留需要强制生效的部分。例如，仅需控制连接顺序时，可仅设置JOIN_ORDER部分。

2.4 对pg_hint_plan生态的影响

路径生成策略机制的最大受益者是pg_hint_plan等第三方提示插件。在新框架下，pg_hint_plan预计可减少约2500行代码，实现更简洁、更可靠的执行计划提示能力。这也标志着PostgreSQL从“抗拒查询提示”到“开放官方扩展接口”的重要转变。

三、分区管理的“平民化”：MERGE/SPLIT PARTITIONS

3.1 从复杂脚本到一行命令

分区表的动态管理一直是PostgreSQL DBA的痛点。在PG 19之前，将多个分区合并为一个，或将一个大分区拆分为多个，往往需要手动创建新分区、迁移数据、删除旧分区等一系列复杂操作，极易出错。PG 17曾尝试引入分区合并与拆分命令，但补丁在发布前不久被回退。PG 19以更稳健的实现方式完成了第二次尝试。

3.2 典型操作示例

以按月份分区的航班预订表为例，合并去年第四季度的三个分区：

-- 合并三个月份分区为一个季度分区
ALTER TABLE bookings_range MERGE PARTITIONS (p2025_10, p2025_11, p2025_12) INTO p2025;

-- 将季度分区重新拆分为月份分区
ALTER TABLE bookings_range SPLIT PARTITION p2025 INTO (
    PARTITION p2025_10 FOR VALUES FROM ('2025-10-01') TO ('2025-11-01'),
    PARTITION p2025_11 FOR VALUES FROM ('2025-11-01') TO ('2025-12-01'),
    PARTITION p2025_12 FOR VALUES FROM ('2025-12-01') TO ('2026-01-01')
);

3.3 当前限制与未来展望

目前，MERGE和SPLIT PARTITIONS命令会在整个执行期间对父表加排他锁，因此不应在业务高峰期运行。但这一功能为未来的锁级别优化和并行执行奠定了坚实基础。对于需要定期调整分区策略的数据生命周期管理场景，这一特性显著降低了运维复杂度。

四、逻辑复制：告别“重启恐惧症”

4.1 动态WAL级别调整

长期以来，PostgreSQL逻辑复制和逻辑解码（CDC）的使用存在一个令人困扰的痛点：必须在数据库启动前将wal_level设置为logical并重启实例。这意味着即便没有任何逻辑复制任务运行，数据库也要持续承担logical级别WAL日志带来的额外I/O和存储开销。

PG 19彻底解决了这一问题。系统现在可根据逻辑复制槽的存在与否，自动动态调整WAL级别：创建第一个逻辑复制槽时，有效WAL级别自动提升至logical；当最后一个逻辑槽被删除或失效后，有效级别降回replica。新增的只读GUC参数effective_wal_level可用于监控当前实际生效的WAL级别。

4.2 发布订阅的精细控制

PG 19还允许在ALTER PUBLICATION中使用EXCEPT TABLE子句，实现对发布订阅中特定表排除的精细控制。这一改进在租户隔离和选择性数据同步场景中尤为实用。

五、pg_dump增强：统计信息的“完整闭环”

5.1 从PG 18到PG 19：统计信息能力的持续进化

PG 18引入了表级和列级统计信息的导出与恢复能力，解决了大版本升级后因统计信息丢失导致执行计划不准的“升级即事故”风险。PG 19在此基础上更进一步，新增了扩展统计信息（Extended Statistics）的完整支持。

5.2 扩展统计信息的导出与恢复

通过--statistics参数，pg_dump现在可以导出由CREATE STATISTICS创建的三种扩展统计类型（ndistinct、dependencies和MCV），并通过pg_restore_extended_stats函数在目标数据库中恢复。

使用示例：

# 仅导出统计信息（不含表结构和数据）
pg_dump --statistics-only -d production_db > stats.sql

# 导出表结构+统计信息（用于测试环境搭建）
pg_dump --schema-only --statistics -d production_db > schema_with_stats.sql

导出文件为纯SQL格式，包含三个还原函数pg_restore_relation_stats（表级）、pg_restore_attribute_stats（列级）和pg_restore_extended_stats（扩展级）的调用语句，可直接在目标环境执行导入。

5.3 生产环境对齐的“杀手级”能力

这一特性对生产环境问题复现和测试环境对齐具有极高价值。DBA可以从生产库导出精准的统计信息并在测试库中恢复，使查询规划器在两个环境中做出相同的决策，从根本上消除“生产复现不了”的困境。

六、REPACK内核化：表膨胀治理进入新时代

6.1 从外部工具到原生命令

pg_repack长期以来作为PostgreSQL社区最受欢迎的第三方运维工具之一，以“在线重整表数据、仅需最少锁”的能力解决了VACUUM FULL需要排他锁的痛点。PG 19正式将其核心能力纳入内核，引入了原生命令REPACK，整合了VACUUM FULL（表空间收缩）和CLUSTER（索引有序重排）的核心能力。

6.2 双模式统一语法

基础模式：REPACK table_name; —— 等价于VACUUM FULL，消除表内死元组、重整数据、收缩磁盘空间，解决表膨胀问题。
索引排序模式：REPACK table_name USING INDEX idx_name; —— 等价于CLUSTER，按指定索引物理重排表数据，同步完成空间收缩，大幅提升范围查询性能。

6.3 全流程可观测

新增pg_stat_progress_repack系统视图，实时展示执行阶段、堆元组扫描/写入量、索引重建进度等核心指标，彻底解决旧命令执行过程黑盒的问题。VACUUM FULL和CLUSTER命令仍被保留以确保向下兼容，但在官方文档中不再重点推荐，转而引导用户使用REPACK。

6.4 并发模式的未来展望

社区讨论中已出现并发REPACK的实现思路，通过创建专为REPACK操作保留的独立复制槽池（默认3个槽），有望在后续版本中实现真正意义上的在线表重整，同时避免干扰常规复制槽的资源竞争。

七、其他值得关注的特性

时态表支持：PG 19实现了UPDATE/DELETE FOR PORTION OF语法，允许对时间维度区间数据进行精准的部分更新与删除，是SQL:2023标准的重要落地。
GROUP BY ALL：允许在GROUP BY子句中省略分组列名，自动按SELECT列表中的所有非聚合列分组，简化SQL编写。
file_fdw增强：支持在导入CSV文件时跳过初始行，解决数据文件头部包含说明文字无法直接加载的问题。
EXPLAIN ANALYZE开销降低：使用RDTSC指令替代传统计时方式，显著减少性能分析时的计时开销。

八、升级策略：什么时候升级？

PG 19定位为“实用性版本”——它不是颠覆性革命，而是对长期痛点的精准修复。以下三类场景尤其值得考虑升级：

受困于执行计划不稳定的企业：pg_plan_advice提供原生计划锁定能力，核心业务SQL从此不再“跑偏”。
分区表规模庞大的运维团队：MERGE/SPLIT PARTITIONS将分区管理从复杂脚本简化为一行命令。
使用逻辑复制的CDC场景：动态WAL级别调整彻底消除“开启即永久高负载”的顾虑。

对于多数生产用户，建议在2026年9月/10月正式GA发布后，先在测试环境充分验证，再制定升级计划。PG 19将遵循标准的5年支持周期。

结语：从“多模”到“统一”——PG 19的平台化价值

回顾PG 19的全貌，一条清晰的演进主线浮出水面：

图查询内核化：PostgreSQL首次原生支持图遍历，知识图谱、社交网络等场景不再需要外部扩展。
执行计划锁定：从“被动接受规划器决策”到“主动掌控执行计划”，DBA终于有了官方工具。
分区管理平民化：从复杂脚本到一行命令，动态分区管理进入标准化时代。
逻辑复制降门槛：从“重启恐惧”到“按需启用”，CDC场景的运维成本大幅降低。
统计信息闭环：从“升级即事故”到“统计信息可移植”，测试环境对齐不再是难题。

PG 19真正意义上的突破，不在于任何单一功能的惊艳程度，而在于它正在将PostgreSQL从“一个优秀的关系型数据库”推向“一个统一的多模数据平台”。向量检索、全文搜索、图查询、时态数据处理——这些曾在不同数据库系统中各自为战的能力，正在被PostgreSQL有序纳入同一套SQL语法、同一套事务模型、同一套运维体系之下。

对于企业而言，这意味着数据技术栈的选择正在变得前所未有的简单。对于开发者而言，这意味着学习成本和集成复杂度的大幅降低。而对于PostgreSQL本身而言，2026年正是它从“数据库”向“数据平台”完成角色跃迁的关键之年。

📌 下期预告：第四期——云原生PostgreSQL的分布式架构演进 从Citus到Apache Cloudberry，从阿里云Serverless Pro到Google Cloud主动-主动架构，我们将深度剖析2026年PostgreSQL分布式生态的最新进展，探讨云原生时代PostgreSQL如何应对大规模数据挑战。

（本文数据截至2026年4月，最新动态请以PostgreSQL官方发布为准。）