如果说 PostgreSQL 18 是稳扎稳打的一代,那 19 就是让运维和开发者"尖叫"的一代 —— 零停机 REPACK终于来了,autovacuum 终于学会并行干活了,外键检查直接快 1.8 倍,还有能让前段同学少写一堆代码的 COPY JSON...
我们直接开始。
痛点:以前 REPACK 需要 AccessExclusiveLock,意味着锁表期间业务中断。 DBA 只能在凌晨业务低峰期熬夜操作。
PostgreSQL 19:现在支持 CONCURRENTLY 选项,REPACK 期间业务正常访问。
-- 索引重建,业务照常运行
REPACK INDEX CONCURRENTLY ON my_table;
MVCC 快照 + 逻辑解码保驾护航,零停机不是梦。
痛点:历史原因 autovacuum 始终禁用并行 vacuum,大表 vacuum 吭哧吭哧要很久,膨胀风险居高不下。
PostgreSQL 19:解除封印,autovacuum 也能用并行 workers 了。
SET autovacuum_max_parallel_workers = 4;
和手动 VACUUM 一样的并行索引清理能力,autovacuum 自此真正智能化。
痛点:autovacuum 以前按"发现顺序"处理表,结果急表等死,非急表占着资源。
PostgreSQL 19:引入优先级机制,高优先级表(比如频繁更新的核心表)优先处理。
配合 pg_stat_autovacuum_scores 视图,膨胀风险一览无余:
SELECT relname, score, would_vacuum, would_analyze
FROM pg_stat_autovacuum_scores;
痛点:以前开启校验和必须停机,风险高、窗口难找。
PostgreSQL 19:pg_checksums 支持在线模式,running 集群上直接启用/禁用。
数据完整性保障,now or never,不用再等"完美窗口"。
痛点:只知道 query慢,不知道慢在 I/O 还是 CPU。
PostgreSQL 19:EXPLAIN 新增 IO 选项,显示预取距离、I/O 请求次数:
EXPLAIN (IO, ANALYZE) SELECT * FROM t WHERE ...;
-- 输出示例:
-- I/O: read distance=128KB, requests=4
结合 auto_explain.log_io GUC,自动记录慢查询的 I/O 行为。
痛点:开 EXPLAIN ANALYZE 监控时,引入的额外开销本身就能让 query 变慢两倍。
PostgreSQL 19:x86-64 平台大幅优化,移动大量行查询的开销从 2 倍降到 1.2 倍,TPCH 复杂查询监控开销降低约 20%。
-- 现在可以更放心地使用 EXPLAIN ANALYZE
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM big_table;
PostgreSQL 19:新增 PGSTAT_KIND_LOCK 统计类型,跟踪锁等待次数和等待时间。
-- 查看锁等待情况
SELECT * FROM pg_stat_locks; -- 新增强力视图
DBA 定位锁竞争问题,终于不用靠"玄学"了。
痛点:复杂查询的统计信息有时会误导 planner,手动调优苦不堪言。
PostgreSQL 19:提供稳定执行计划选择和强制特定计划的能力。
这是调优疑难杂症的终极武器,planner 也不一定总是对的,对吧?
痛点:postgres_fdw 跨节点查询,每次都要重新 ANALYZE,网络开销不小。
PostgreSQL 19:restore_stats 选项,直接从远程服务器导入统计信息:
CREATE SERVER my_remote FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (restore_stats 'true');
DBA 可以集中管理统计信息,减少跨节点 ANALYZE 的延迟。
痛点:导出数据给前端,JSON 格式要写一堆 json_agg()/json_build_object(),还容易出错。
PostgreSQL 19:一行 SQL 直接导出 NDJSON:
COPY (SELECT id, name, created_at FROM users) TO STDOUT WITH FORMAT JSON;
-- {"id":1,"name":"张三","created_at":"2025-01-01"},{"id":2,"name":"李四","created_at":"2025-01-02"}...
-- 合法 JSON 数组?
COPY (SELECT ...) TO STDOUT WITH FORMAT JSON, force_array true;
-- [{"id":1,"name":"a"},{"id":2,"name":"b"},...]
psql \copy 搞定导出,前端直呼专业。
PostgreSQL 19:实现 ISO/IEC 9075-16:2023 SQL/PGQ 标准,图查询语法进入 PostgreSQL:
-- 创建属性图
CREATE PROPERTY GRAPH my_graph;
-- 图模式匹配
SELECT * FROM GRAPH_TABLE(my_graph
MATCH (a) -> (b) -> (c)
WHERE a.type = 'user'
COLUMNS (a.name AS user, b.name AS product, c.action));
# psql 查看属性图
\dG my_graph
图数据库能力,PostgreSQL 帮你省钱。
痛点:业务数据常有"有效期"概念(如订单、合同、库存),手动写起止时间条件容易漏。
PostgreSQL 19:SQL 标准的时态更新/删除:
UPDATE t FOR PORTION OF valid_at
FROM '2005-01-01' TO '2006-01-01'
SET status = 'expired';
再也不用写 WHERE valid_at @> '2005-06-01'::tstzrange 了。
痛点:批量导入数据时,外键检查是性能瓶颈。
PostgreSQL 19:批量索引探测优化,FK 检查缓冲 64 行后批量探测。
实测 int PK/FK,100万行:快 1.8 倍。数据导入脚本可以少等一杯咖啡的时间。
PostgreSQL 19:新增 ltrim()、rtrim()、btrim()、lower()、upper()、initcap()、replace()、split_part() 方法:
SELECT '{"name": "JOHN DOE"}'::jsonpath.JSON -> 'name' -> '$.name.initcap()';
-- "John Doe"
SELECT '{"url": "https://example.com"}'::jsonpath.JSON -> 'url' -> '$.url.replace("https", "http")';
-- "http://example.com"
JSON 清洗不用再跑到应用层处理了。
痛点:导出数据库/角色的完整 DDL,要写一堆 pg_dump --schema-only,还得自己拼装。
PostgreSQL 19:三个新函数,一个 SQL 搞定:
-- 导出数据库 DDL
SELECT pg_get_database_ddl('mydb'::regdatabase, pretty => true);
-- 导出角色 DDL(含成员关系)
SELECT pg_get_role_ddl('myrole'::regrole, memberships => true);
-- 导出表空间 DDL
SELECT pg_get_tablespace_ddl('mytbs'::regtablespace);
代码审查、迁移、环境复现——DBA 提效利器。
痛点:逻辑解码快照以前是实例级别,一个数据库的长事务会阻塞同实例下其他数据库的 REPACK。
PostgreSQL 19:快照现在可以数据库级别隔离,操作更灵活。
痛点:同一 IP 上托管多个 PostgreSQL 实例,要配置不同 SSL 证书,SNI 不支持就只能多 IP。
PostgreSQL 19:服务端 TLS 支持 Server Name Indication (SNI),一个 IP,多域名证书,妥妥的。
云厂商和 PaaS 平台管理员狂喜。
痛点:之前 AIO worker 数量需要手动调优,配置复杂。
PostgreSQL 19:I/O worker 池大小自动调整,只需设置范围:
io_min_workers=2 -- 最小 workers
io_max_workers=8 -- 最大 workers
io_worker_idle_timeout=60s
io_worker_launch_interval=100ms
PostgreSQL 自己学会了"弹性伸缩"。
PostgreSQL 19 是近几代中体感最强的版本:
如果觉得有收获,转发给你身边用 PostgreSQL 的同事和朋友。
本文基于 PostgreSQL 19 开发分支分析整理,部分特性以最终发布版本为准。