PostgreSQL 19前瞻：一次兼顾创新与实用的版本升级

关注

原创最新推荐文章于 2026-11-07 10:08:23 发布 243 阅读 AI 写同款· GEO 优化 ›

量子安全选举软件：基于NIST后量子密码标准的端到端可验证系统后量子密码学是应对量子计算威胁的前沿加密技术，其核心原理基于数学难题的复杂性，如格密码和基于哈希的签名。在选举安全领域，传统公钥密码体系面临量子计算机的潜在破解风险，而抗量子算法能确保选举数据的长期保密性。ML-DSA-65和ML-KEM-768等NIST标准化算法通过模块格问题提供量子级别的安全保障，适用于政府选举和高安全性决策场景。端到端可验证投票机制结合这些技术，不仅保护选票传输和存储，还允许选民确认计票准确性，自然收敛到量子安全选举软件这一实现方案。阅读详情

每一个 PostgreSQL 版本似乎都有属于自己的“性格”。有些版本因某项重量级特性而被铭记，有些版本则解决了长期存在的核心痛点；还有一些版本，则通过大量细节优化，让升级后的日常使用体验变得更加顺畅。而几乎每一个 PostgreSQL 大版本发布，都会伴随着性能方面的持续提升。

PostgreSQL 19 更像是一个兼具多种特质的版本。内置的 REPACK CONCURRENTLY 为大型生产数据库带来了重要的运维体验提升，并且成为核心能力的一部分。与此同时，也不乏备受关注的重要特性，例如 SQL 属性图查询能力（SQL/PGQ）。逻辑复制持续完善，VACUUM、EXPLAIN、COPY、分区、监控、性能优化以及查询优化器等多个领域也迎来了稳步演进。这些改进或许不像某些明星特性那样耀眼，但对于生产环境而言，却意味着更加稳定、高效和易于维护的数据库系统。

与所有 Beta 版本一样，部分细节在正式发布前仍可能发生变化。不过，随着 PostgreSQL 19 Beta 的发布，现在已经是了解即将到来的变化，以及评估这些变化对生产环境影响的最佳时机。

开箱即用的 REPACK

对于长期运行 PostgreSQL 的系统而言，几乎都曾面临过表膨胀治理、表重写或者数据重组的需求。然而，VACUUM FULL 或 CLUSTER 所需要持有的锁，往往意味着生产业务无法接受的停机窗口。

围绕这一问题，PostgreSQL 生态长期以来形成了成熟的扩展解决方案，其中最具代表性的便是 pg_repack。扩展生态的繁荣本身便说明了一件事情：这一需求真实存在，并且足够重要。

PostgreSQL 19 将全新的 REPACK 命令正式纳入核心系统，同时支持 REPACK CONCURRENTLY。对于生产环境用户而言，REPACK CONCURRENTLY 很可能会成为一个比大多数发布说明阅读者预想中更加重要的特性。

分区功能变得更加实用

近年来，PostgreSQL 的分区能力取得了显著进步。从最初“理论上可用，但需要深入理解内部机制和各种限制条件”，逐渐演进为更加成熟且易于使用的能力。

PostgreSQL 19 在此基础上进一步增加了分区合并与分区拆分能力。这一变化看似简单，却解决了实际生产环境中的一个常见问题。

分区策略往往是在信息并不充分的情况下制定的。初期设计的分区方案可能适用于当前业务，但随着时间推移，业务负载可能发生变化，数据保留周期可能发生调整，数据增长速度可能超出预期，甚至部分分区可能变得异常庞大，而另外一些分区则非常小。

能够对分区进行拆分与合并，为数据库架构演进提供了更大的灵活性。

-- Combine Q1 and Q2 into a single partition 
ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;

-- Split the Q3 partition into monthly intervals
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')
);

优秀的数据库设计通常并非一成不变，而是能够随着业务持续演进。PostgreSQL 提供更多无需重建整个体系即可调整架构的能力，正是其长期适用于生产环境的重要原因之一。

逻辑复制持续成熟

逻辑复制已经成为 PostgreSQL 最近多个版本持续重点投入的领域之一。数据库迁移、版本升级、报表系统建设、数据同步、选择性复制，以及越来越多的高可用与运维场景，都在依赖逻辑复制能力。

PostgreSQL 19 在这一领域继续补齐关键能力。其中最重要的一项改进是：序列值（Sequence）开始支持同步。对于依赖序列生成主键的业务系统而言，仅同步数据而不同步序列状态，往往会在业务切换后带来问题。数据虽然已经同步完成，但下一个生成的 ID 却可能并不处于正确位置。

PostgreSQL 19 新增了序列同步能力，使订阅端能够更加准确地保持与发布端一致。除此之外，还新增了：

Publication 支持 ALL SEQUENCES
增强序列同步错误报告能力
优化订阅刷新过程中的序列处理逻辑

另一个值得关注的增强是：Publication 在发布全部表时支持使用 EXCEPT 子句排除指定表。这更加符合实际生产环境中的使用方式——通常需要同步“几乎所有数据”，但又希望排除少数特殊表。

此外，当需要逻辑复制能力时，wal_level=replica 可以自动启用逻辑复制功能，同时新增 effective_wal_level 用于展示系统实际生效的 WAL 级别。这意味着更少的配置陷阱以及更高的系统可观测性。逻辑复制依然是一项复杂能力，但随着每个版本的演进，它正逐渐从一项高级特性成长为 PostgreSQL 标准运维工具集中的基础组成部分。

Autovacuum 变得更加智能，也更加可观测

VACUUM 可以说是 PostgreSQL 最具代表性的机制之一。很多系统在运行多年后，随着表膨胀、事务回卷风险或者查询性能波动的出现，才真正开始关注 VACUUM 的内部工作机制。

PostgreSQL 19 在这一领域带来了多项值得关注的增强。首先，Autovacuum 开始支持并行 Vacuum Worker，并支持全局和单表级别配置。对于大型表和大型索引而言，这意味着 PostgreSQL 在后台维护任务上的处理能力将进一步增强。

-- Allow up to 4 parallel workers globally for autovacuum processes 
ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;

同时，新版本引入了新的评分机制，用于控制 Autovacuum 的表处理顺序。这一能力十分重要，因为 Autovacuum 本质上始终在进行资源权衡：哪些表最需要优先处理，哪些任务应该稍后执行。更加智能的优先级排序，能够帮助系统在问题真正影响业务之前完成维护工作。

-- Adjust the priority scoring just for this table:
-- Give insert-based vacuuming a massive urgency boost (3.0),
-- while dropping the normal update/delete vacuum urgency (0.5) since rows are rarely deleted.
ALTER TABLE application_logs SET (
    autovacuum_vacuum_insert_score_weight = 3.0,
    autovacuum_vacuum_score_weight = 0.5
);

除此之外，新版本还新增了 pg_stat_autovacuum_scores 视图，用于展示评分决策过程。同时，VACUUM 和 ANALYZE 进度视图中也增加了更多信息；VACUUM VERBOSE 和 Autovacuum 日志中增加了内存使用情况和并行执行信息；此外，还新增了独立的 log_autoanalyze_min_duration 参数。

PostgreSQL 19 在维护能力上的一个重要主题，就是提升可观测性。数据库自动完成后台维护工作固然重要，而能够清晰解释这些工作为何发生、如何执行，则更加重要。

SQL 属性图查询正式进入 PostgreSQL

PostgreSQL 19 中最引人关注的新特性之一，便是 SQL/PGQ，即 SQL 属性图查询能力。图数据库在过去多年间经历过多次技术热潮，而某些业务场景确实非常适合采用顶点与边的建模方式，例如：

欺诈检测
推荐系统
网络分析
权限关系分析
供应链分析
组织架构分析

-- sample property graph
CREATE PROPERTY GRAPH store_graph
VERTEX TABLES (
    customers LABEL customer,
    orders LABEL "order"
)
EDGE TABLES (
    customer_orders 
        SOURCE customers 
        DESTINATION orders 
        LABEL placed_order
);

SQL/PGQ 最有价值的一点在于，它并没有要求放弃关系模型，而是在现有关系数据之上增加了一种新的查询方式。这也非常符合 PostgreSQL 一贯的发展路线。

JSONB 的出现并未取代关系表；全文检索能力并未要求部署独立搜索引擎；扩展机制也并不意味着需要维护数据库分支。如今，SQL/PGQ 为 PostgreSQL 增加了一种基于图结构理解关系数据的新视角。

真正值得关注的，并不是“PostgreSQL 成为了图数据库”，而是“已经选择的数据库平台变得更加全面”。这一差异虽然微妙，却十分重要。对于开发者而言，这意味着许多图查询场景未来可能无需引入新的数据库产品、同步链路以及额外的运维复杂度。而在生产环境中，更少的系统组件通常意味着更低的风险。

COPY 持续变得更加实用

COPY 是 PostgreSQL 中一个低调但极其重要的功能。数据导入与导出几乎存在于所有业务场景，因此即使只是一些小幅优化，也能够带来显著价值。

PostgreSQL 19 为 COPY 带来了多项增强。首先，COPY FROM 支持跳过多行 Header。这一能力在处理来自供应商系统、内部工具或者各种导出程序生成的 CSV 文件时非常实用，因为这些文件往往包含额外的元数据描述信息。同时，COPY FROM 新增 ON_ERROR SET_NULL 选项，允许将非法输入自动转换为 NULL。这为“导入失败”和“提前完成全部数据清洗”之间提供了新的选择。

-- Imagine a file where a price column occasionally contains 'N/A' or 'MISSING' instead of a numeric value
COPY product_catalog (product_id, title, price_usd)
FROM '/path/to/dirty_products.csv' 
WITH (
    FORMAT CSV, 
    HEADER, 
    ON_ERROR SET_NULL
);

此外，COPY TO 开始支持 JSON 输出格式，包括直接输出为单个 JSON 数组。

-- Export an entire table directly into a cleanly formatted, valid JSON array 
COPY customers TO '/path/to/customers_export.json' WITH (FORMAT JSON, ARRAY true);

与此同时，分区表也支持直接导出，而无需再通过 COPY (SELECT …) 实现。这些改进或许不会改变世界，但能够持续改善日常数据处理体验。

SQL 易用性改进

PostgreSQL 19 同样带来了多项开发者关注的 SQL 语法增强。GROUP BY ALL 可以自动对所有非聚合、非窗口函数表达式进行分组。这对于探索性分析和报表查询场景而言，能够有效减少 SQL 编写复杂度。

-- Using GROUP BY ALL
SELECT 
    category,
    manufacturer,
    COUNT(*) as total_items,
    AVG(price) as avg_price
FROM inventory_products
GROUP BY ALL;

窗口函数新增了 IGNORE NULLS 和 RESPECT NULLS 支持，包括：

lead()
lag()
first_value()
last_value()
nth_value()

对于时序分析场景中获取最近一个非空值的需求而言，这将极大简化实现方式。

INSERT ... ON CONFLICT DO SELECT ... RETURNING 同样是一个非常实用的增强。Upsert 已经成为现代应用开发中的常见模式，而能够直接返回冲突记录，则进一步提升了灵活性。

INSERT INTO tags (tag_name) 
VALUES ('postgres')
ON CONFLICT (tag_name) DO SELECT
RETURNING tag_id;

此外，PostgreSQL 还新增了 UPDATE FOR PORTION OF 和 DELETE FOR PORTION OF，进一步完善时态数据处理能力。同时，随机时间函数 RANDOM() 也得到了扩展。

全面的性能提升

PostgreSQL 19 在查询优化器与执行器层面继续进行了大量优化工作。优化范围包括：

Anti Join
Semi Join
常量折叠
Append Path 下的增量排序
Join 前聚合处理
Join 选择率计算
函数统计信息等多个领域

相比简单列举优化项，更重要的结论在于：PostgreSQL 正在不断提升对常见查询模式的识别能力，并尽可能减少不必要的计算开销。部分聚合操作现在能够在 Join 之前完成，从而减少参与计算的数据量；更多 NOT IN 与 LEFT JOIN 场景能够自动转换为高效的 Anti Join；Memoize 在 EXPLAIN 中拥有更好的可观测性；基数排序（Radix Sort）进一步提升排序性能；外键检查速度得到优化；COPY FROM 的文本与 CSV 输入开始支持 SIMD 指令加速。

这些优化大多数情况下并不需要修改应用代码。升级完成后，PostgreSQL 将自动拥有更高概率生成更优执行计划。这也是数据库性能优化中最理想的一种形式。