万字深度解析 PostgreSQL 19 Beta 1：2026 年数据库内核最重磅升级——从并行 Vacuum 到 SQL/PGQ 属性图的全方位革新

前言

2026 年 6 月 4 日，PostgreSQL 全球开发组正式发布了 PostgreSQL 19 Beta 1，这是继 PostgreSQL 18 引入异步 I/O 子系统之后，数据库内核迎来的又一次里程碑式升级。从性能到开发者体验，从安全到可观测性，PostgreSQL 19 一口气带来了数十项改进，其中多项直接触及数据库内核最核心的执行器和优化器。

作为一名后端工程师，我最关心的是：这次升级到底解决了什么问题？有哪些新特性值得我们从现在就关注并在生产环境落地？本文将结合官方 Release Notes 和实际代码示例，对 PostgreSQL 19 Beta 1 进行全方位深度解析。

一、背景：为什么 PostgreSQL 19 值得关注

PostgreSQL 每两年发布一个大版本，每年的 6 月前后发布 Beta 1，9-10 月正式发布 GA（General Availability）。PostgreSQL 19 的 Beta 1 于 2026 年 6 月 4 日发布，这意味着正式版预计在 2026 年 9-10 月发布。

从版本演进路线来看，PostgreSQL 19 承接了 18 版本的异步 I/O 基础设施，并在其上构建了更高层的优化能力。同时，19 版本也是 PostgreSQL 在 JIT 编译、安全、TLS 证书管理等领域做重大调整的版本——JIT 编译从默认启用改为默认禁用、LZ4 成为默认压缩算法、SNI 支持 TLS 证书动态分发等。

这些变化说明 PostgreSQL 正在从「功能丰富的通用数据库」向「面向生产环境的高度可控数据库」演进。

二、性能革新：让 INSERT 和 VACUUM 跑出两倍速

2.1 外键约束下的 INSERT 性能翻倍

这是 PostgreSQL 19 最引人注目的性能改进之一：在有外键约束检查的场景下，INSERT 性能提升最高可达 2 倍。

在 PostgreSQL 的早期版本中，当表之间存在外键约束时，INSERT 操作需要对外键关联的父表进行约束检查。旧版实现中，这个检查是逐行串行执行的——每插入一行，就要对父表加锁并检查一次。虽然 PostgreSQL 在高并发场景下通过 MVCC 提供了优秀的并发能力，但在外键检查这个特定路径上，优化空间一直存在。

PostgreSQL 19 对这个路径做了重新设计。新的实现引入了批量外键检查机制：积累一定数量的待检查行后，一次性地对父表进行批量约束验证，而不是逐行加锁检查。这大幅减少了锁竞争和往返次数。

代码示例：验证外键 INSERT 性能提升

-- 准备测试环境：创建父子表
DROP TABLE IF EXISTS child CASCADE;
DROP TABLE IF EXISTS parent CASCADE;

CREATE TABLE parent (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE child (
    id SERIAL PRIMARY KEY,
    parent_id INTEGER NOT NULL REFERENCES parent(id),
    value NUMERIC
);

-- 插入父表数据（1000行）
INSERT INTO parent (name)
SELECT 'parent_' || i FROM generate_series(1, 1000) AS i;

-- 创建索引（生产环境必须有）
CREATE INDEX ON child (parent_id);

-- 批量插入子表数据（有外键约束）
\timing on
INSERT INTO child (parent_id, value)
SELECT 
    (random() * 999 + 1)::INTEGER,
    random() * 1000
FROM generate_series(1, 100000) AS i;

在 PostgreSQL 18 及以前，这个 INSERT 100000 行的操作在有外键约束时可能需要数十秒；在 PostgreSQL 19 中，同样的操作理论上可以缩短到原来的一半甚至更多（具体提升取决于硬件和并发压力）。

生产建议：外键约束下的批量 INSERT 性能提升对批量导入 ETL 任务、高频写入场景（如 IoT 数据采集）有显著意义。如果你的应用有大量 INSERT INTO ... SELECT 或 COPY 导入操作，升级到 PostgreSQL 19 应该能直接看到收益。

2.2 并行 Autovacuum：Vacuum 终于可以多线程了

这是 PostgreSQL 历史上 Vacuum 模块最大的架构变革。

长期以来，PostgreSQL 的 Autovacuum worker 只能单线程运行。虽然 autovacuum_max_workers 参数可以控制同时启动多少个 worker，但每个 worker 本身只能单线程处理一张表。如果一张大表的 B-tree 索引有上百万个页面需要清理，单个 worker 必须逐页面顺序扫描，这在 TPC-C 这种高写入负载下会成为维护瓶颈。

PostgreSQL 19 引入了 并行 Autovacuum，通过新的 autovacuum_max_parallel_workers 参数控制每个 Vacuum 任务最多可以启动多少个并行 worker：

-- PostgreSQL 19 新增参数：每个 Vacuum 任务的并行 worker 数上限
SET autovacuum_max_parallel_workers = 4;  -- 默认 2

-- 监控 Vacuum 并行状态
SELECT 
    schemaname,
    relname,
    started_by,  -- PostgreSQL 19 新增：报告任务发起者（autovacuum / manual / vacuumdb）
    mode,        -- PostgreSQL 19 新增：报告 Vacuum 运行模式（lazy / full / truncate / indexes）
    heap_blks_total,
    heap_blks_scanned,
    heap_blks_vacuumed,
    index_vacuum_count,
    max_dead_tuples,
    num_dead_tuples
FROM pg_stat_progress_vacuum;

新增的 started_by 和 mode 列是 PostgreSQL 19 监控方面的关键改进。在旧版本中，你只能看到 pg_stat_progress_vacuum 显示的扫描进度，但无法区分是 Autovacuum 触发的还是手动 VACUUM 触发的，也看不到具体的 Vacuum 策略模式。现在，有了这两个新列，运维人员可以精确诊断 Vacuum 行为。

新的 Vacuum 策略：查询时标记可见页面

PostgreSQL 19 还引入了一种新的 Vacuum 策略，可以在查询扫描表的过程中直接标记页面为「可见」，而不需要等待 Vacuum worker 专门处理。这意味着某些读多写少的场景下，Vacuum 的未来工作量会显著减少。

REPACK 命令：在线重建表，零停机

-- PostgreSQL 19 新增：在线重建表
-- 旧表数据会逐批迁移到新表，CONCURRENTLY 选项允许不阻塞并发读写
REPACK TABLE orders CONCURRENTLY;

-- 不带 CONCURRENTLY 的 REPACK 会在执行期间持有 AccessExclusiveLock（会阻塞写操作）
REPACK TABLE orders;

REPACK 命令的引入填补了 PostgreSQL 长期以来的一个空白：在线重建表、回收表膨胀（bloat）、重排物理存储顺序，而不需要依赖 CREATE TABLE AS + 重命名 + 重建索引这种需要短暂锁的操作。CONCURRENTLY 选项意味着你可以在生产表上安全地执行 REPACK，而不用担心业务中断。

2.3 查询优化器：Anti-Join、Eager Aggregation 与 EXPLAIN AIO

Anti-Join 优化

Anti-Join（反连接）是 SQL 优化中一个经典但复杂的场景：当查询需要找出在 A 表中但不在 B 表中的记录时（通常用 NOT IN 或 NOT EXISTS 表达），优化器可以选择不同的执行策略。PostgreSQL 19 扩展了 Anti-Join 的适用场景，对更多类型的子查询引入了 Anti-Join 优化路径。

Eager Aggregation（急切聚合）

-- 启用 Eager Aggregation（PostgreSQL 19 默认开启）
SET enable_eager_agg = on;  -- 新增参数

-- 示例：聚合操作现在可以更高效地处理中间结果
SELECT 
    customer_id,
    SUM(amount),
    AVG(amount),
    COUNT(*)
FROM orders
WHERE order_date >= '2026-01-01'
GROUP BY customer_id;

Eager Aggregation 是一种新的执行策略：优化器在处理聚合操作前，先将所有参与计算的行「急切地」汇聚到一起，而不是边扫描边聚合。这对某些需要先汇聚再处理的查询模式（如带有多表 JOIN 的聚合查询）有显著的性能收益。

EXPLAIN ANALYZE 新增 AIO 统计

EXPLAIN (ANALYZE, BUFFERS, IO ON)
SELECT * FROM orders WHERE customer_id = 42;

PostgreSQL 19 的 EXPLAIN ANALYZE 新增了 IO ON 选项，可以直接展示查询对异步 I/O 子系统的使用情况：

Gather  (cost=...)
  Workers Planned: 4
  AIO Workers: 4          -- PostgreSQL 19 新增：展示 AIO worker 使用情况
  AIO Total Read: 1.23 MB  -- AIO 子系统总共读取的数据量
  AIO Total Time: 12.34 ms
  ->  Seq Scan on orders ...

这使得 DBA 可以直接量化查询对 I/O 的使用效率，而不需要借助外部监控工具。

2.4 LISTEN/NOTIFY 扩展性改进

PostgreSQL 的 LISTEN/NOTIFY 机制是实现消息队列和事件驱动架构的基础设施。PostgreSQL 19 改进了多通道场景下的扩展性，减少了高并发通知场景下的锁竞争。

三、开发者体验：SQL 标准全面升级

3.1 SQL/PGQ 属性图查询：关系型数据库的图查询能力

这是 PostgreSQL 19 最具战略意义的新功能之一。

SQL/PGQ（Property Graph Queries）是 SQL 标准中新增的属性图查询扩展，允许用户使用标准 SQL 语法执行图遍历查询，而不需要借助专门的图数据库（如 Neo4j）。属性图由节点（顶点）和边（关系）组成，每个节点和边都可以附加属性（键值对）。

-- PostgreSQL 19 新增：SQL/PGQ 属性图

-- 步骤 1：创建属性图
CREATE PROPERTY GRAPH eCommerceGraph
  VERTEX TABLES (
    customers LABEL 'Customer',
    products  LABEL 'Product',
    orders    LABEL 'Order'
  )
  EDGE TABLES (
    orders    KEY(order_id) 
              SOURCE KEY(customer_id) REFERENCES customers(customer_id)
              DEST   KEY(product_id) REFERENCES products(product_id)
              LABEL 'contains'
  );

-- 步骤 2：使用图遍历语法查询
SELECT *
FROM GRAPH_TABLE (eCommerceGraph
    MATCH (c:Customer) -[o:contains]-> (p:Product)
    WHERE c.region = '华东'
    COLUMNS (
      c.customer_id,
      c.name       AS customer_name,
      p.product_id AS product_id,
      p.name       AS product_name,
      COUNT(*)     AS purchase_count
    )
)
ORDER BY purchase_count DESC
LIMIT 20;

这段查询的意思是：从属性图中找出华东地区购买过商品的客户，统计他们购买最多的产品。如果用传统 SQL 实现类似查询，需要写多层 JOIN 和子查询，而图查询语法让这个过程更直观。

生产级应用场景：

• 推荐系统：基于用户-商品-评分三元组的协同过滤
• 社交网络：好友推荐、关系链分析
• 风控系统：资金流向追踪、异常交易图谱
• 供应链：多级供应商关系网络分析

注意：PostgreSQL 19 的 SQL/PGQ 实现依赖 contrib 扩展（需要 CREATE EXTENSION pg_graph 或类似扩展），具体的扩展包可能需要单独安装或从 PostgreSQL 官方 contrib 目录编译。Beta 1 阶段的实现可能存在限制，建议在测试环境中验证后再考虑生产使用。

3.2 GROUP BY ALL：少写 GROUP BY 子句的艺术

这是 PostgreSQL 19 最「甜」的开发体验改进。

-- 旧写法：必须把所有非聚合列、手动列举
SELECT 
    region,
    category,
    status,
    SUM(amount)   AS total_amount,
    COUNT(*)      AS order_count,
    AVG(amount)   AS avg_amount
FROM orders
WHERE order_date >= '2026-01-01'
GROUP BY region, category, status;

-- PostgreSQL 19 新写法：GROUP BY ALL，自动包含所有非聚合非窗口列
SELECT 
    region,
    category,
    status,
    SUM(amount)   AS total_amount,
    COUNT(*)      AS order_count,
    AVG(amount)   AS avg_amount
FROM orders
WHERE order_date >= '2026-01-01'
GROUP BY ALL;

GROUP BY ALL 会自动把所有未出现在聚合函数或窗口函数中的 SELECT 列纳入 GROUP BY 子句。这不是标准 SQL 特性（而是 PostgreSQL 特有的扩展），但它极大地简化了数据分析查询的编写——特别是当你只需要对大多数列做聚合时。

应用场景：数据报表、BI 查询、即时分析查询（Ad-hoc Query）。当你需要对一个宽表做多维度聚合时，GROUP BY ALL 可以让你少写几十行列名。

3.3 增强的 jsonpath 函数

PostgreSQL 的 jsonpath（JSON 路径查询语言，用于 JSONB 类型）在 19 版本中大幅扩展：

-- PostgreSQL 19 新增 jsonpath 函数
-- 这些函数现在可以在 jsonpath 查询中直接使用

-- 假设数据结构：{"name": "张三", "address": "上海市浦东新区"}
SELECT jsonb_path_query(
    '{"name": "张三", "address": "上海市浦东新区"}'::jsonb,
    '$.name.lower()'         -- PostgreSQL 19：直接在 jsonpath 中调用 lower()
);

SELECT jsonb_path_query(
    '{"name": "ZHANG SAN", "address": "shanghai"}'::jsonb,
    '$.name.initcap()'       -- PostgreSQL 19：首字母大写
);

SELECT jsonb_path_query(
    '{"tags": "a,b,c,d"}'::jsonb,
    '$.tags.split(";")'     -- PostgreSQL 19：字符串分割
);

-- trim 家族
SELECT jsonb_path_query(
    '{"note": "   hello   "}'::jsonb,
    '$.note.ltrim().rtrim()'  -- 左右去空格
);

-- 替换操作
SELECT jsonb_path_query(
    '{"message": "old text here"}'::jsonb,
    '$.message.replace("old", "new")'  -- PostgreSQL 19：字符串替换
);

这些增强让 jsonpath 从一个「够用但局限」的 JSON 查询语言，进化成了可以替代部分 Python/JavaScript JSON 处理逻辑的数据库原生能力。对于以 JSONB 为核心存储结构的场景（如日志存储、多租户配置、动态表单），这意味着可以在数据库层完成更多的数据转换，减少应用层的处理负担。

3.4 分区表管理：MERGE 和 SPLIT PARTITIONS

-- 合并分区
ALTER TABLE orders MERGE PARTITIONS 
    (orders_2026_q1, orders_2026_q2) 
    INTO (orders_2026_h1);

-- 拆分分区
ALTER TABLE orders SPLIT PARTITION 
    orders_2026_h1 AT (DATE '2026-07-01')
    INTO (orders_2026_h1a, orders_2026_h1b);

以前修改分区结构需要重建表（ALTER TABLE ... ATTACH/DETACH PARTITION 操作繁琐）。MERGE PARTITIONS 和 SPLIT PARTITIONS 提供了原生的分区重组能力，对时间序列数据和按范围分区的场景非常友好。

3.5 INSERT ... ON CONFLICT DO SELECT RETURNING

-- PostgreSQL 19：upsert 后返回冲突行
INSERT INTO products (id, name, price, stock)
VALUES 
    (1, '鼠标', 99.00, 100),
    (2, '键盘', 299.00, 50),
    (3, '显示器', 1999.00, 30)
ON CONFLICT (id) DO UPDATE
    SET stock = products.stock + EXCLUDED.stock
RETURNING *;  -- 返回所有受影响行（包括冲突行和更新行）

3.6 WAIT FOR LSN：读己之所写

这是 PostgreSQL 19 对读写分离架构最重要的改进。

在使用流复制（Streaming Replication）的 PostgreSQL 集群中，应用写主库后立刻读副本，可能会遇到「读不到刚才写入的数据」的问题（因为数据还没有被复制到副本）。这被称为 "read-your-writes" 一致性问题。

-- PostgreSQL 19：等待特定 LSN 被副本回放
-- 1. 执行写入
INSERT INTO orders (customer_id, amount) VALUES (42, 999.00);
-- 获取当前 LSN
SELECT pg_current_wal_lsn() AS write_lsn;
-- write_lsn = 0/3A8F456

-- 2. 在只读副本连接中，等待这个 LSN 被回放
WAIT FOR LSN '0/3A8F456';  -- PostgreSQL 19 新增命令

-- 3. 现在可以安全读取，确保拿到了刚才写入的数据
SELECT * FROM orders WHERE customer_id = 42;

这使得应用可以在副本上实现「写后读一致性」，而不需要强制走主库读。配合连接池（如 PgBouncer）和路由中间件，可以大幅降低主库的读压力。

3.7 random() 支持日期时间类型

-- PostgreSQL 19 之前
SELECT TIMESTAMP '2026-01-01' + 
       (random() * INTERVAL '365 days') AS random_date;

-- PostgreSQL 19：random() 原生支持日期时间
SELECT random(DATE '2026-01-01', DATE '2026-12-31') AS random_date;
SELECT random(TIMESTAMP '2026-01-01 00:00:00', 
              TIMESTAMP '2026-12-31 23:59:59') AS random_timestamp;

四、安全升级：TLS 证书和密码管理的现代化

4.1 SNI 动态 TLS 证书分发

Server Name Indication（SNI）是 TLS 协议中允许客户端在 TLS 握手阶段就告诉服务器「我想要连接哪个域名」的能力。传统上，一个 PostgreSQL 服务器只能服务于一张 TLS 证书——所有连接共享同一个证书，不管客户端请求的是哪个域名。

PostgreSQL 19 引入了 pg_hosts.conf 文件，实现基于 SNI 的动态证书分发：

# /var/lib/postgresql/data/pg_hosts.conf
# PostgreSQL 19 新增：SNI 证书映射配置

# 对于 api.example.com，使用 api.crt / api.key
hostssl api.example.com  all  0.0.0.0/0  cert clientcert=verify-full
certfile /etc/ssl/certs/api.example.com.crt
keyfile  /etc/ssl/private/api.example.com.key

# 对于 analytics.example.com，使用另一套证书
hostssl analytics.example.com  all  0.0.0.0/0  cert clientcert=verify-full
certfile /etc/ssl/certs/analytics.example.com.crt
keyfile  /etc/ssl/private/analytics.example.com.key

# 默认回退证书
hostssl all  all  0.0.0.0/0  cert clientcert=verify-full
certfile /etc/ssl/certs/default.crt
keyfile  /etc/ssl/private/default.key

这对于提供多租户数据库服务或需要为不同业务域使用不同证书的场景非常有价值——比如同一个 PostgreSQL 实例服务多个客户，每个客户有自己的数据库和证书，以前需要 HAProxy 或 PgBouncer 来做 TLS 终结，现在 PostgreSQL 原生支持了。

4.2 密码过期警告与 md5 认证警告

-- PostgreSQL 19 新增：提前 N 天警告密码即将过期
SET password_expiration_warning_threshold = '7 days';  -- 默认 7 天

-- PostgreSQL 19 新增：控制 md5 认证警告行为
SET md5_password_warnings = on;  -- 连接成功后显示 md5 警告
-- 客户端会看到：
-- WARNING:  md5 authentication is deprecated. Consider using scram-sha-256 instead.

PostgreSQL 19 对 md5 认证的警告机制体现了项目组推动安全升级的决心。md5 认证已经在 PostgreSQL 17 中被标记为废弃，19 版本继续施压——通过客户端警告提示管理员尽快迁移到 SCRAM-SHA-256。

五、可观测性：pg_stat_lock、pg_stat_recovery 与进程级日志

5.1 pg_stat_lock：按锁类型统计

-- PostgreSQL 19 新增：每种锁类型的统计信息
SELECT 
    locktype,
    database,
    relation::regclass        AS table_name,
    page,
    tuple,
    virtualxid,
    transactionid,
    classid,
    objid,
    objsubid,
    virtualtransaction,
    pid,
    mode,
    granted,
    fastpath,
    lock_status   -- PostgreSQL 19 新增：锁状态（granted / waiting）
FROM pg_stat_lock;

pg_stat_lock 是对现有锁监控能力的重要补充。它以视图的形式提供了跨连接、跨表的锁统计信息，配合 lock_status 列（granted / waiting）可以快速定位：哪些表被哪种锁阻塞了多久，哪些查询长时间持有锁不放。

5.2 pg_stat_recovery：恢复状态可见性

-- PostgreSQL 19 新增：查看流复制/物理恢复的详细状态
SELECT 
    pid,
    usesysid,
    usename,
    application_name,
    client_addr,
    state,           -- streaming / catchup / backup / waiting
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag,
    sync_state       -- sync / async / potential
FROM pg_stat_recovery;

这个视图对 DBA 运维流复制集群非常有用。以前需要综合 pg_stat_replication、pg_control_checkpoint 等多个数据源才能了解恢复进度，现在一个视图全部搞定。

5.3 进程级日志级别控制

-- PostgreSQL 19：按进程类型设置不同日志级别
ALTER SYSTEM SET log_min_messages = 'warning';  -- 默认级别
ALTER SYSTEM SET log_min_messages = 'debug1' FOR (autovacuum_worker);
ALTER SYSTEM SET log_min_messages = 'info' FOR (background_writer);
-- autovacuum worker 记录 debug1 细节
-- background writer 记录 info 级别
-- 其他进程使用默认的 warning

-- WAL 全页写入字节数统计（出现在 VACUUM 和 ANALYZE 日志中）
-- log_line_prefix 设置 %f 格式可以显示 WAL 文件信息
-- PostgreSQL 19 在 VACUUM/ANALYZE 日志中新增了 full_page_writes_bytes 字段
-- 帮助识别哪些维护操作产生了大量 WAL

六、逻辑复制：序列值同步与按需启用

6.1 序列值终于会同步了

这是 PostgreSQL 逻辑复制领域最困扰用户的长期 bug 终于被修复了。

在旧版 PostgreSQL 中，逻辑复制（Logical Replication）不复制序列（SEQUENCE）的当前值。这意味着：主库上表 A 的自增列已经到 50000，备库上的同一序列还停留在 1。当你 Failover 到备库或做主备切换时，INSERT 会产生主键冲突。

PostgreSQL 19 修复了这个 bug：逻辑复制现在会自动同步序列值。不过需要注意的是，这个修复在 Beta 1 中可能还不完全稳定，建议在测试环境中充分验证。

-- 验证序列是否参与逻辑复制
SELECT 
    s.relname AS sequence_name,
    r.relname AS table_name,
    s.relowner::regrole AS owner
FROM pg_class s
JOIN pg_depend d ON s.oid = d.refobjid
JOIN pg_class r ON d.objid = r.oid
WHERE s.relkind = 'S'
  AND d.deptype = 'a';

6.2 CREATE PUBLICATION ... EXCEPT：发布所有表的简化写法

-- PostgreSQL 19：发布所有表，排除特定表
CREATE PUBLICATION full_db_pub EXCEPT TABLE orders_archive, logs_old;

-- 这比逐个列举所有表要简洁得多
-- 非常适合数据仓库场景：发布全库，但排除不需要实时同步的历史分区

6.3 按需启用逻辑复制

-- PostgreSQL 19：无需重启服务器即可启用逻辑复制
-- 旧版：必须设置 wal_level = logical 后重启服务器
-- PostgreSQL 19：可以在运行时切换

ALTER SYSTEM SET wal_level = logical;
-- PostgreSQL 19 会自动处理 WAL 级别切换，不需要重启

-- 查看当前实际生效的 WAL 级别（只读，受实际限制）
SHOW effective_wal_level;
-- 即使你设置了 wal_level = logical，如果系统压力大，effective_wal_level 
-- 可能被限制在 replica，这是 PostgreSQL 19 对资源控制的精细化管理

七、postgres_fdw：查询联邦性能大幅提升

postgres_fdw 是 PostgreSQL 内置的外部数据包装器，允许一个 PostgreSQL 实例直接查询另一个 PostgreSQL 实例。PostgreSQL 19 对 postgres_fdw 做了两个重要改进：

7.1 数组操作下推

-- PostgreSQL 19：数组操作现在可以下推到远程服务器执行
SELECT * FROM remote_orders
WHERE customer_id = ANY(ARRAY[101, 202, 303, 404, 505]::integer[]);

-- PostgreSQL 19 之前：ANY(ARRAY[...]) 会先获取远程表全部数据，再在本地过滤
-- PostgreSQL 19 之后：ARRAY 操作被翻译成 SQL 标准 ANY 表达式，下推到远程服务器执行
-- 网络传输数据量大幅减少

7.2 远程统计信息收集

-- PostgreSQL 19：postgres_fdw 会自动收集并使用远程表的统计信息
-- 以便本地查询优化器做出更好的执行计划

-- 这个功能默认开启，PostgreSQL 会定期通过 postgres_fdw 连接
-- 向远程服务器查询统计信息（pg_class, pg_statistic 等）
-- 本地优化器再也不用「盲估」远程表的数据分布了

八、重要变更与升级注意事项

8.1 JIT 编译默认关闭

-- PostgreSQL 19：JIT 编译默认禁用
-- 旧版（18及以前）：jit = on 为默认值
-- PostgreSQL 19：jit = off 为默认值

SHOW jit;  -- 默认 off

-- 为什么这样改？
-- 1. JIT 编译在某些 OLTP 短查询场景下反而增加开销（编译时间 > 节省时间）
-- 2. JIT 依赖 LLVM，启用会增加内存占用
-- 3. 社区认为应该让管理员主动评估是否需要 JIT，而不是默认启用

-- 如果你的工作负载是复杂 OLAP 查询（大量聚合、JOIN、嵌套循环），可以重新启用
SET jit = on;
SET jit_above_cost = 100000;  -- 超过这个成本的查询才启用 JIT

这个决策有争议但也有充分理由：JIT 编译对 OLTP 短查询没有价值甚至有害，关闭默认是务实的选择。但对于 OLAP 场景，建议在测试环境中对比开关 JIT 的性能差异再做决定。

8.2 默认压缩算法改为 LZ4

-- PostgreSQL 19：TOAST 默认压缩算法从 pglz 改为 lz4
SHOW default_toast_compression;  -- 默认 lz4

-- LZ4 vs pglz：
-- LZ4 压缩比略低（约 5-10%），但解压速度是 pglz 的 3-5 倍
-- 对读多写少、频繁解压的场景（分析型工作负载），LZ4 性能优势明显

8.3 RADIUS 认证移除

PostgreSQL 19 移除了 RADIUS 认证支持（RADIUS 是早期企业网络认证协议）。如果你的系统仍在使用 auth透传 = 'radius'，需要迁移到其他认证方案（SASL、LDAP 或 PAM）。

8.4 vacuumdb --analyze-only 行为变更

# PostgreSQL 19：vacuumdb --analyze-only 现在默认分析分区表
vacuumdb --analyze-only --jobs 4 my_database

# 以前需要手动加上 --analyze-in-stages
# 现在 --analyze-only 默认会分析分区表的各个子分区

九、实战：PostgreSQL 19 Beta 1 升级路径

9.1 版本路线图

PostgreSQL 17  →  PostgreSQL 18  →  PostgreSQL 19
     GA Sep/2025      GA Sep/2026      GA Sep/2026（预计）

PostgreSQL 18 于 2025 年 9 月正式发布，19 预计在 2026 年 9-10 月发布。PostgreSQL 14 将于 2026 年 11 月 12 日停止接收补丁更新，仍在使用 PG 14 的团队需要尽快规划升级路径。

9.2 从 PostgreSQL 17/18 升级到 19

# 方式一：pg_upgrade（推荐，零停机升级）
# 1. 安装 PostgreSQL 19
# 2. 停止 PostgreSQL 17/18
pg_ctl stop -D /var/lib/postgresql/17/data

# 3. 初始化 Postgre 19 集群（在同一台机器上）
/usr/lib/postgresql/19/bin/initdb -D /var/lib/postgresql/19/data

# 4. 修改配置文件，继承 17 的配置
# 确保 postgresql.conf 中的参数与 17 兼容（特别是新增参数有默认值）

# 5. 执行 pg_upgrade
/usr/lib/postgresql/19/bin/pg_upgrade \
    --old-datadir=/var/lib/postgresql/17/data \
    --new-datadir=/var/lib/postgresql/19/data \
    --old-bindir=/usr/lib/postgresql/17/bin \
    --new-bindir=/usr/lib/postgresql/19/bin \
    --link  # 硬链接模式，速度更快

# 6. 升级后运行 VACUUM ANALYZE
./analyze_new_cluster.sh

# 7. 检查 pg_stat_statements 等扩展是否需要重新安装

9.3 配置对比检查清单

-- 升级前在 PG 18 中检查这些参数
SELECT name, setting, unit, boot_val
FROM pg_settings
WHERE name IN (
    'jit',
    'default_toast_compression',
    'autovacuum_max_parallel_workers',
    'enable_eager_agg',
    'io_min_workers',
    'io_max_workers',
    'password_expiration_warning_threshold',
    'md5_password_warnings'
);

9.4 Grease Mode：生态兼容性检查

PostgreSQL 19 Beta 1 包含一个临时的 "Grease Mode"（润滑模式），用来测试 PostgreSQL 协议与生态工具（连接池、ORM、迁移工具、监控工具等）的兼容性。

-- 启用 Grease Mode（测试环境）
SET postgres_fdw.grease_mode = on;

-- Grease Mode 会模拟一些旧协议行为，确保 pg_dump、pg_restore、
-- PgBouncer、各种语言的 PostgreSQL 驱动（JDBC、psycopg2、npgsql 等）
-- 仍然能正常工作

十、PostgreSQL 19 对 2026 年后端技术格局的影响

10.1 属性图查询：PostgreSQL 向图数据库领域进军

SQL/PGQ 的引入让 PostgreSQL 在功能上与 Neo4j、Cassandra 等图数据库形成了直接竞争。对于已经在使用 PostgreSQL 的团队，这意味着：不需要引入新的图数据库，只需要在现有的 PostgreSQL 实例上启用 SQL/PGQ 扩展，就能获得图遍历能力。

这对推荐系统、风控系统、供应链优化等场景有重大影响——团队可以减少技术栈复杂度，同时享受 PostgreSQL 成熟的生态（备份、监控、高可用）带来的便利。

10.2 并行 Vacuum + REPACK：在线表维护的黄金组合

长期以来，PostgreSQL 的表膨胀（bloat）问题让 DBA 头疼不已——VACUUM FULL 需要排他锁，CREATE TABLE AS + 重命名需要短暂不可写窗口。PostgreSQL 19 的 REPACK ... CONCURRENTLY 配合并行 Vacuum worker，第一次让在线表重建变得简单可靠。

这对长期运行的生产系统特别有意义：经过多年运行的表，膨胀率可能高达 30-50%，REPACK 可以安全地回收这些空间，而不影响业务。

10.3 pg_plan_advice 和 pg_stash_advice：AI 辅助的 SQL 优化

PostgreSQL 19 引入了两个实验性扩展：pg_plan_advice（查询计划建议）和 pg_stash_advice（将建议自动应用到查询标识符）。这预示着 PostgreSQL 未来可能在内核层面集成 AI 辅助优化能力——类似于阿里云 ADB、TiDB 的 SQL Advisor，但以内核扩展的形式原生存在。

10.4 开发者体验升级：SQL 正在变得更现代

GROUP BY ALL、增强的 jsonpath、random() 对日期时间的原生支持……这些看似小的改进，实际上在反映一个趋势：SQL 方言正在快速现代化。PostgreSQL 19 让编写复杂查询变得更加简洁，减少了开发者的认知负担。

结语

PostgreSQL 19 Beta 1 是一个「内核级」的大版本升级。它不仅带来了数十个新特性，更重要的是，这些特性从底层（I/O 子系统、执行器、查询优化器）到应用层（SQL/PGQ、jsonpath、GROUP BY ALL）形成了一个完整的技术栈。

作为后端工程师，我们最应该关注以下几个方向：

1. 立即测试：如果有高并发写入 + 外键约束的场景，PostgreSQL 19 的 INSERT 性能翻倍值得在测试环境中验证。
2. 规划升级：PostgreSQL 14 在 2026 年 11 月停止维护，建议现在就开始规划升级路径。
3. 关注 SQL/PGQ：2026 年正式 GA 后，这可能是 PostgreSQL 历史上最重要的功能扩展之一，值得提前学习。
4. JIT 评估：如果你的 OLAP 工作负载依赖 JIT 加速，升级后需要重新测试和调整 JIT 参数。
5. 安全配置：JIT 默认关闭、LZ4 默认启用、TLS SNI 证书分发等变化需要在升级后检查配置。

PostgreSQL 19 Beta 1 的发布，让我们看到了开源数据库领域持续创新的活力。从 9.6 到 19，二十多年的版本演进，PostgreSQL 始终在「世界最先进的开源关系型数据库」这条路上稳步前进。

参考资源：

• PostgreSQL 19 Beta 1 官方发布说明：https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/
• PostgreSQL 19 完整 Release Notes：https://www.postgresql.org/docs/19/release-19.html
• PostgreSQL 19 官方文档：https://www.postgresql.org/docs/19/
• PostgreSQL 19 Beta 测试指南：https://www.postgresql.org/developer/beta/