PostgreSQL 19 Beta 1 深度解析：SQL/PGQ图查询、时态操作、并行Vacuum——60+新特性重新定义关系型数据库

2026年6月4日，PostgreSQL Global Development Group 正式发布 PostgreSQL 19 Beta 1。作为"全球最先进的开源关系型数据库"，PG19 带来了超过60项新特性，覆盖图查询、性能优化、逻辑复制、安全认证、时态数据操作等多个领域。本文从原理到实战，全面拆解 PG19 的技术亮点。

目录

1. 引言：为什么 PG19 是里程碑式版本
2. SQL/PGQ：无需图数据库的图查询
3. 时态数据操作：UPDATE/DELETE FOR PORTION OF
4. 性能大阅兵：AIO、并行Vacuum、外键优化
5. 开发者体验升级
6. 逻辑复制与查询联邦
7. 安全与监控新特性
8. 破坏性变更与迁移指南
9. 总结与展望

1. 引言：为什么 PG19 是里程碑式版本

PostgreSQL 19 的开发周期跨越了整整两年（2024-2026），是 PostgreSQL 历史上特性最密集的版本之一。与 PG18 专注于异步 I/O（AIO）基础架构不同，PG19 在 AIO 基础上做了大量生产级增强，同时引入了多项"终结痛点"的功能。

1.1 核心亮点一览

1.2 发布时间线

• 2026年4月：特性冻结
• 2026年6月：Beta 1 发布
• 2026年9-10月：预计正式版发布

2. SQL/PGQ：无需图数据库的图查询

2.1 背景：为什么关系型数据库需要图查询？

图数据模型在社交网络、知识图谱、供应链、反欺诈等场景中天然优势明显。传统方案是"关系库+图库"双写，带来数据一致性、同步延迟、运维复杂度三重痛点。

SQL:2023 标准第16部分（SQL/PGQ）定义了在关系表上执行图模式匹配的标准化语法。PostgreSQL 19 是首个完整实现该标准的主流关系型数据库。

2.2 核心概念

属性图（Property Graph）：在现有关系表上声明顶点（VERTEX）和边（EDGE），把表映射成图。

-- 在现有表上定义属性图
CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (
    users LABEL person PROPERTIES (id, name, age)
  )
  EDGE TABLES (
    follows
    SOURCE KEY (follower_id) REFERENCES users (id)
    DESTINATION KEY (followed_id) REFERENCES users (id)
    LABEL follows
    PROPERTIES (created_at)
  );

2.3 GRAPH_TABLE 查询语法

使用类似 Cypher 的模式匹配语法进行图遍历：

-- 查找 Alice 关注的人关注了谁（朋友的朋友）
SELECT *
FROM GRAPH_TABLE (social_graph
  MATCH (a IS person WHERE a.name = 'Alice')
        -[IS follows]->(b IS person)
        -[IS follows]->(c IS person)
  COLUMNS (c.name AS friend_of_friend)
);

2.4 与独立图数据库对比

2.5 实战：知识图谱查询示例

-- 定义文章-作者-标签的知识图谱
CREATE PROPERTY GRAPH knowledge_graph
  VERTEX TABLES (
    articles LABEL article PROPERTIES (id, title, created_at),
    authors   LABEL author  PROPERTIES (id, name, email),
    tags      LABEL tag     PROPERTIES (id, name)
  )
  EDGE TABLES (
    authored_by SOURCE users (id) DESTINATION articles (id) LABEL wrote,
    has_tag    SOURCE articles (id) DESTINATION tags (id) LABEL tagged
  );

-- 查询：找出与某作者使用相同标签的其他作者
SELECT DISTINCT other.name
FROM GRAPH_TABLE (knowledge_graph
  MATCH (a IS author WHERE a.name = '张三')
        -[:wrote]->(:article)
        -[:tagged]->(t IS tag)
        <-[:tagged]-(:article)
        <-[:wrote]-(other IS author)
  WHERE other.name <> '张三'
  COLUMNS (other.name)
);

3. 时态数据操作：UPDATE/DELETE FOR PORTION OF

3.1 背景

时态数据（Temporal Data）是指具有时间有效性的数据，例如"某员工在2020-2023年任职于A部门"。传统做法需要手动维护时间范围，且更新历史数据非常繁琐。

PG18 引入了时态约束（Temporal Constraints），PG19 进一步补全了 DML 侧的时态操作。

3.2 FOR PORTION OF 语法

-- 假设有表存储用户订阅记录（带时间范围）
CREATE TABLE subscriptions (
  user_id    INT,
  plan       TEXT,
  valid_from DATE,
  valid_to   DATE,
  PERIOD FOR valid_period (valid_from, valid_to)
);

-- 传统方式：需要手动拆分时间范围
-- PG19 方式：直接对时间范围的"一部分"进行操作
UPDATE subscriptions
FOR PORTION OF valid_period
  FROM DATE '2026-01-01' TO DATE '2026-06-30'
SET plan = 'premium'
WHERE user_id = 42;

这条语句会自动将原来跨该时间范围的记录拆分成多条，只更新指定时间范围内的部分。

3.3 与 PG18 时态约束的关系

PG18：定义时间范围约束（PERIOD FOR、无重叠约束）
PG19：对时间范围执行 DML（UPDATE/DELETE FOR PORTION OF）

二者配合，实现了完整的时态数据管理能力，无需应用层处理时间拆分逻辑。

4. 性能大阅兵：AIO、并行Vacuum、外键优化

4.1 异步 I/O（AIO）子系统增强

PG18 引入了 io_method 参数（sync/worker），PG19 对其做了关键增强：

-- io_method = worker 时，自动扩缩 I/O Worker 数量
SET io_method = 'worker';
SET io_min_workers = 2;   -- 最小 I/O worker 数
SET io_max_workers = 8;   -- 最大 I/O worker 数（根据 I/O 负载自动调整）

原理：PG19 的 AIO worker 不再固定数量，而是根据当前 I/O 队列深度动态调整，避免空闲时浪费进程、繁忙时阻塞等待。

4.2 并行 Autovacuum

这是 DBA 期盼多年的功能。PG19 引入 autovacuum_max_parallel_workers 参数：

-- 允许同时运行最多 4 个并行 vacuum  worker
SET autovacuum_max_parallel_workers = 4;

新 Autovacuum 评分系统：PG19 还引入了 autovacuum 评分机制，根据表的死行比例、上次 vacuum 时间等因素动态排序，优先处理最"脏"的表。

4.3 外键检查性能提升（最高 2x）

PG19 优化了外键约束检查的实现，在批量 INSERT 场景下性能提升最高达 2倍：

-- 测试：插入 100 万行带外键约束的数据
-- PG18：~45秒
-- PG19：~22秒（取决于具体场景）
INSERT INTO orders (user_id, amount)
SELECT g, random() * 1000
FROM generate_series(1, 1000000) g;

原理：PG19 在外键检查中引入了批量验证优化，将逐行检查改为批量探查，大幅减少了索引扫描次数。

4.4 Anti-Join 优化

Anti-join（NOT EXISTS / LEFT JOIN ... WHERE ... IS NULL）是常见慢查询模式。PG19 对其做了专项优化：

-- PG19 能更好地优化此类查询
SELECT * FROM users u
WHERE NOT EXISTS (
  SELECT 1 FROM banned_users b WHERE b.id = u.id
);

4.5 Eager Aggregation

新参数 enable_eager_aggregate 允许优化器在 JOIN 之前先执行聚合，减少 JOIN 的数据量：

SET enable_eager_aggregate = on;

-- 以下查询可能在 JOIN 前先聚合 orders 表
SELECT u.name, COUNT(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.name;

5. 开发者体验升级

5.1 GROUP BY ALL 语法

写聚合查询时，GROUP BY 子句需要列出所有非聚合列，非常繁琐。PG19 引入 GROUP BY ALL：

-- 传统写法
SELECT region, department, COUNT(*), AVG(salary)
FROM employees
GROUP BY region, department;

-- PG19 写法（自动将所有非聚合、非窗口列加入 GROUP BY）
SELECT region, department, COUNT(*), AVG(salary)
FROM employees
GROUP BY ALL;

注意：GROUP BY ALL 仅包含 SELECT 列表中"直接出现"的非聚合列，不包含通过 * 展开的列。

5.2 INSERT ... ON CONFLICT DO SELECT ... RETURNING

PG19 允许在 ON CONFLICT 时返回冲突的行，而不仅仅是执行 UPDATE 或 INSERT：

-- 尝试插入，如果冲突则返回冲突的行信息
INSERT INTO users (id, name, email)
VALUES (1, 'Alice', 'alice@example.com')
ON CONFLICT (id) DO SELECT *
RETURNING *;

这个特性对于"获取或创建"（get-or-create）模式非常有用，避免了先 SELECT 再 INSERT 的竞态条件。

5.3 WAIT FOR LSN：副本上的"读写一致性"

在读写分离架构中，主库写入后，副本可能因为延迟读不到最新数据。PG19 引入 WAIT FOR LSN：

-- 在主库写入
INSERT INTO messages (content) VALUES ('Hello') RETURNING *;

-- 在副本上等待直到收到指定的 LSN
WAIT FOR LSN '0/12345678';

-- 现在可以安全读取刚才写入的数据
SELECT * FROM messages WHERE content = 'Hello';

5.4 jsonpath 字符串函数扩展

PG19 为 jsonpath 增加了多个字符串处理函数：

-- 新增函数：lower(), upper(), initcap(), replace(), split_part(), trim()
SELECT jsonb_path_query(
  '{"name": "Hello World"}',
  '$.name.lower()'
);  -- 返回 "hello world"

SELECT jsonb_path_query(
  '{"items": "a,b,c"}',
  '$.items.split_part(",", 2)'
);  -- 返回 "b"

6. 逻辑复制与查询联邦

6.1 序列值复制

在线升级场景的一个经典痛点是：序列（SEQUENCE）的值不会通过逻辑复制同步，导致切换后主键冲突。

PG19 解决了这个问题：

-- 发布端
CREATE PUBLICATION my_pub FOR ALL TABLES WITH (publish = 'insert,update,delete,sequence');

-- 订阅端自动同步序列当前值
CREATE SUBSCRIPTION my_sub
  CONNECTION 'host=primary port=5432 dbname=mydb'
  PUBLICATION my_pub;

6.2 在线启用逻辑复制

过去，启用逻辑复制需要将 wal_level 从 replica 改为 logical 并重启数据库。PG19 允许在某些情况下在线启用：

-- 查看当前生效的 WAL 级别
SHOW effective_wal_level;

-- PG19：wal_level=replica 时也可启用逻辑复制（有限功能）
-- 完整功能仍需 wal_level=logical（但可在运行时调整，不必重启）
ALTER SYSTEM SET wal_level = 'logical';
SELECT pg_reload_conf();  -- 部分场景可在线生效

6.3 CREATE PUBLICATION ... EXCEPT

发布所有表，但排除少数几张：

CREATE PUBLICATION my_pub
  FOR ALL TABLES
  EXCEPT TABLE users, passwords;  -- 排除敏感表

6.4 postgres_fdw 性能优化

查询联邦（Query Federation）通过 postgres_fdw 访问远程 PostgreSQL 的性能大幅提升：

• 数组操作下推：远程支持数组操作，不再需要把所有数据拉到本地执行
• 远程表统计信息：本地规划器可以获取远程表的统计信息，生成更优的执行计划

-- 启用远程统计信息获取
CREATE FOREIGN TABLE remote_orders (
  id INT,
  user_id INT,
  amount NUMERIC
)
SERVER remote_pg
OPTIONS (table_name 'orders', use_remote_estimate 'true');

7. 安全与监控新特性

7.1 SNI 支持（Server Name Indication）

一台 PostgreSQL 服务器现在可以根据客户端请求的主机名，出示不同的 TLS 证书：

# pg_hosts.conf
# hostname       cert_file                       key_file
db.example.com   /etc/ssl/db.example.com.crt    /etc/ssl/db.example.com.key
api.example.com  /etc/ssl/api.example.com.crt   /etc/ssl/api.example.com.key

这对于 SaaS 多租户场景非常有用。

7.2 密码过期预警

-- 设置密码过期预警阈值（默认 7 天）
SET password_expiration_warning_threshold = '7 days';

-- 用户登录时，如果密码即将过期，会收到 WARNING

7.3 新监控视图

pg_stat_lock：按锁类型统计锁信息

SELECT * FROM pg_stat_lock;

pg_stat_recovery：恢复操作详细状态

SELECT * FROM pg_stat_recovery;

7.4 EXPLAIN ANALYZE 支持 AIO 统计

-- 查看查询的 AIO 使用情况
EXPLAIN (ANALYZE, IO) SELECT * FROM large_table WHERE id > 10000;

8. 破坏性变更与迁移指南

8.1 需要注意的变更

8.2 在线 checksum 切换

PG19 支持在线启用/禁用数据校验和：

-- 在线启用 checksum（过去需要离线操作）
SELECT pg_enable_data_checksums();

8.3 REPACK CONCURRENTLY

在线重建表的新方式，比传统的 pg_repack 工具更原生：

-- 在线重建表，不阻塞写入
REPACK TABLE orders CONCURRENTLY;

9. 总结与展望

PostgreSQL 19 是一个"六边形战士"级别的版本：

• 图查询能力让 PG 可以直接替代部分图数据库场景
• 时态操作补全了时间数据管理的最后一块拼图
• 性能优化（并行 vacuum、外键加速、AIO 增强）让 PG 在大规模场景下更有竞争力
• 开发者体验（GROUP BY ALL、ON CONFLICT DO SELECT、WAIT FOR LSN）大幅减少样板代码
• 逻辑复制增强（序列同步、在线启用）让在线升级更加平滑

随着 Beta 1 的发布，PG19 已进入最后的质量打磨阶段。建议在生产环境升级前，充分测试应用兼容性，特别关注 JIT 默认关闭和 toast 压缩变更带来的影响。

参考链接：

• PostgreSQL 19 Beta 1 Release Notes
• SQL/PGQ 文档
• pg_plan_advice 扩展

本文基于 PostgreSQL 19 Beta 1 撰写，正式版发布时部分细节可能有调整。