PostgreSQL 19 深度实战：当关系数据库学会图查询——从 SQL/PGQ 到并行 Autovacuum 的生产级完全指南

2026 年 6 月 4 日，PostgreSQL 19 Beta 1 正式发布。这不是一次常规的版本迭代——它带来的 SQL/PGQ 图查询能力，让关系数据库第一次在不引入新存储引擎的前提下，原生支持属性图模式匹配；它的并行 Autovacuum 和在线校验和切换，则直指生产环境运维的两大痛点。本文从架构原理到代码实战，逐层拆解 PG19 的每一项关键变更，帮你判断：升级还是观望？

一、为什么 PostgreSQL 19 值得你提前关注

每个大版本的 PostgreSQL 发布都有"封面特性"——17 是逻辑复制增强，18 是异步 I/O。而 19 的封面特性是 SQL/PGQ：一种让关系数据库直接执行图查询的 ISO 标准实现。

但这远不是全部。PG19 还解决了生产环境中最让人头疼的问题：

• Autovacuum 终于支持并行了——大表的 vacuum 不再是单线程的噩梦
• 数据校验和可以在线开关了——不再需要停库跑 pg_checksums
• 外键检查性能大幅提升——大量外键约束的表终于不用被拖慢
• TOAST 默认压缩从 pglz 换成 lz4——大字段存储瘦身
• JIT 默认关闭了——承认之前的成本估算不可靠

这些变化的共同主题是：PostgreSQL 在收窄"理论上很强大"和"生产上真好用"之间的差距。

二、SQL/PGQ：让 SQL 直接查询图

2.1 图查询的痛点与 SQL/PGQ 的定位

先说清楚一个核心误解：SQL/PGQ 不是把 PostgreSQL 变成了一个图数据库。

图数据库（Neo4j、Memgraph）的核心卖点是"免索引邻接"（index-free adjacency）——每个顶点直接持有指向相邻边的指针，遍历成本是 O(度) 而非 O(log n)。这种存储结构在深层、可变长度的路径查询上有结构性优势。

但现实是：绝大多数生产环境中的"图查询"都是浅层、固定深度的。"找出我朋友最近的购买记录"、"查找某个用户的三度关联账户"——这些查询在关系模型上只是 2-3 跳的 JOIN，但因为要用递归 CTE 和多层自连接来表达，代码可读性极差。

SQL/PGQ 解决的正是这个表达力问题。它的实现方式是一个查询重写器：你在关系表上声明属性图元数据，用类 Cypher 的模式匹配语法写查询，重写器把图模式翻译成关系 JOIN 树，交给现有规划器执行。

你现有的索引、现有的成本模型、现有的执行引擎——全部原样工作。

2.2 声明属性图

假设你有一个社交场景：people 表存人，friendships 表存好友关系，purchases 表存购买记录。

-- 基础表结构
CREATE TABLE people (
    id          BIGINT PRIMARY KEY,
    name        TEXT NOT NULL,
    birth_year  INT,
    city        TEXT
);

CREATE TABLE friendships (
    id          BIGINT PRIMARY KEY,
    person_a    BIGINT REFERENCES people(id),
    person_b    BIGINT REFERENCES people(id),
    since       DATE NOT NULL,
    strength    INT DEFAULT 1  -- 关系强度 1-10
);

CREATE TABLE purchases (
    id          BIGINT PRIMARY KEY,
    buyer_id    BIGINT REFERENCES people(id),
    product     TEXT NOT NULL,
    amount      NUMERIC(10,2),
    bought_at   TIMESTAMP DEFAULT now()
);

-- 关键索引（重写后的 JOIN 会用到这些）
CREATE INDEX idx_friendships_person_a ON friendships(person_a);
CREATE INDEX idx_friendships_person_b ON friendships(person_b);
CREATE INDEX idx_purchases_buyer_id ON purchases(buyer_id);

声明属性图：

CREATE PROPERTY GRAPH social_graph
    VERTEX TABLES (
        people LABEL Person PROPERTIES (id, name, birth_year, city)
    )
    EDGE TABLES (
        friendships
            SOURCE KEY (person_a) REFERENCES people (id)
            DESTINATION KEY (person_b) REFERENCES people (id)
            LABEL Knows PROPERTIES (since, strength),
        purchases
            SOURCE KEY (buyer_id) REFERENCES people (id)
            DESTINATION KEY (buyer_id) REFERENCES people (id)
            LABEL Bought PROPERTIES (product, amount, bought_at)
    );

注意几点：

• VERTEX TABLES 把关系表映射为顶点，LABEL 是顶点的类型标签
• EDGE TABLES 把关系表映射为边，必须指定 SOURCE 和 DESTINATION
• PROPERTIES 声明哪些列在图查询中可见

2.3 图模式匹配查询

场景 1：找出 Jan 的朋友

传统 SQL：

SELECT p2.name, f.since
FROM people p1
JOIN friendships f ON f.person_a = p1.id
JOIN people p2 ON f.person_b = p2.id
WHERE p1.name = 'Jan';

SQL/PGQ：

SELECT friend_name, since
FROM GRAPH_TABLE (social_graph
    MATCH (a:Person WHERE a.name = 'Jan')-[k:Knows]->(b:Person)
    COLUMNS (b.name AS friend_name, k.since AS since)
);

2 跳查询的对比更明显——传统写法需要 3 个 JOIN，PGQ 仍然是一行 MATCH。

场景 2：朋友的朋友的购买记录（3 跳）

SELECT friend_name, product, amount
FROM GRAPH_TABLE (social_graph
    MATCH
        (a:Person WHERE a.name = 'Jan')-[k1:Knows]->
        (b:Person)-[k2:Knows]->
        (c:Person)-[p:Bought]->
    COLUMNS (c.name AS friend_name, p.product AS product, p.amount AS amount)
);

这在传统 SQL 中需要 5 个 JOIN + 多层 WHERE 过滤，代码量是 PGQ 的 3-4 倍。

场景 3：双向好友（互相关注）

SELECT a_name, b_name
FROM GRAPH_TABLE (social_graph
    MATCH (a:Person)-[k1:Knows]->(b:Person)-[k2:Knows]->(a:Person)
    COLUMNS (a.name AS a_name, b.name AS b_name)
);

用递归 CTE 写这个查询至少 20 行，且性能调优困难。PGQ 的重写器直接生成高效的 JOIN 树。

2.4 重写器内部：从图模式到关系执行计划

理解重写器的行为对性能调优至关重要。让我们看一个重写过程：

-- 输入：图查询
SELECT b_name
FROM GRAPH_TABLE (social_graph
    MATCH (a:Person WHERE a.name = 'Jan')-[k:Knows]->(b:Person)
    COLUMNS (b.name AS b_name)
);

-- 重写器内部等价于：
SELECT b.name AS b_name
FROM people AS a
JOIN friendships AS k ON k.person_a = a.id
JOIN people AS b ON k.person_b = b.id
WHERE a.name = 'Jan';

重写器查找 pg_propgraph_element 系统目录，找到 Person 映射到 people 表，Knows 映射到 friendships 表，然后生成等价的 JOIN。规划器用现有统计信息和成本模型选择执行计划。

这意味着：

1. EXPLAIN ANALYZE 对图查询完全适用
2. 你需要在边表的外键列上建索引，跟普通 JOIN 一样
3. pg_stat_user_tables 的统计信息对图查询同样有效
4. 没有单独的图存储需要维护

2.5 当前限制与未来路线

PG19 的 SQL/PGQ 实现不支持可变长度路径（如 -[k:Knows*1..5]->）。这是最大的限制，也是与 Neo4j 真正拉开差距的地方。

可变长度路径计划在后续版本中实现，但即便实现了，底层的执行模型仍然是关系 JOIN，与 Neo4j 的免索引邻接有结构性差异。对于 6 度分隔式的深层遍历，差距可能达到三个数量级。

选型建议：

三、并行 Autovacuum：大表运维的黎明

3.1 老 Autovacuum 的痛点

在 PG18 及之前，Autovacuum 是单线程的。对于几百 GB 的大表，一次 vacuum 可能跑几小时，期间磁盘 I/O 打满、延迟飙升。更糟的是，多个大表同时需要 vacuum 时，它们会排队等待，而不是并行执行。

虽然 PG13 就引入了 VACUUM PARALLEL 手动命令，但 Autovacuum 守护进程从不会自动使用并行——它永远单线程运行。

3.2 PG19 的并行 Autovacuum

PG19 新增了两个配置：

# 全局配置：Autovacuum 最多使用的并行 worker 数
autovacuum_max_parallel_workers = 2

# 也可以在表级别设置
ALTER TABLE large_table SET (autovacuum_parallel_workers = 4);

当 Autovacuum 决定 vacuum 一张大表时，它会像手动 VACUUM PARALLEL 一样启动后台 worker 并行清理。

实战配置建议：

# postgresql.conf 关键参数组合
autovacuum_max_workers = 6           # 增加 autovacuum worker 数量
autovacuum_max_parallel_workers = 2  # 每个 vacuum 任务最多 2 个并行 worker
max_parallel_maintenance_workers = 4 # 确保有足够的并行槽位

需要注意： autovacuum_max_parallel_workers 的 worker 来自 max_parallel_workers 的共享池。如果你的查询也大量使用并行执行，需要适当增大 max_parallel_workers。

3.3 表级精细控制

不同大小的表需要不同策略：

-- 大表：用更多并行 worker 加速
ALTER TABLE orders SET (autovacuum_parallel_workers = 4);

-- 中等表：适度并行
ALTER TABLE users SET (autovacuum_parallel_workers = 2);

-- 小表或写入频繁的表：保持单线程，避免争抢资源
ALTER TABLE sessions SET (autovacuum_parallel_workers = 0);

3.4 监控并行 Autovacuum

PG19 新增了 pg_stat_autovacuum_scores 视图，可以查看每张表的 autovacuum 评分细节：

SELECT relname, score, vacuum_count, autovacuum_count
FROM pg_stat_autovacuum_scores
ORDER BY score DESC
LIMIT 10;

这个评分系统是 PG19 的另一个重要变化——Autovacuum 现在用评分来决定优先 vacuum 哪张表，而不是简单的"最老脏页优先"。新配置参数：

autovacuum_freeze_score_weight = 1.0          # 冻结紧迫度权重
autovacuum_multixact_freeze_score_weight = 1.0 # 多事务冻结权重
autovacuum_vacuum_score_weight = 1.0           # 脏页权重
vacuum_insert_score_weight = 1.0               # 插入权重
autovacuum_analyze_score_weight = 1.0          # 分析权重

通过调整权重，你可以让 Autovacuum 更关注事务 ID 冻结紧迫性（避免 wraparound），或者更关注统计信息过期（避免慢查询）。

四、异步 I/O Worker 自动管理

PG18 引入了 io_method = worker 的异步 I/O 模式，但需要手动配置后台 worker 数量，配少了性能不够，配多了浪费资源。

PG19 让异步 I/O Worker 自动伸缩：

io_method = worker                   # 使用 worker 模式
io_min_workers = 1                   # 最少保留 1 个 worker
io_max_workers = 8                   # 最多扩展到 8 个 worker
io_worker_idle_timeout = 300s        # 空闲 5 分钟后回收
io_worker_launch_interval = 100ms    # 每 100ms 最多启动 1 个 worker

这个设计解决了两个问题：

1. 冷启动性能：不再需要预热 worker 池，按需启动
2. 资源弹性：I/O 密集期自动扩容，空闲期自动缩容

与 PG18 的对比：

实战建议： 如果你在 PG18 上已经在用 io_method = worker，升级到 PG19 后移除固定 worker 数量配置，改用自动伸缩。对于 SSD 存储，io_max_workers = 4-8 通常足够；NVMe 可以尝试更高值。

五、外键性能革命

5.1 问题背景

外键约束在每次 INSERT/UPDATE 时都需要检查引用完整性。对于有大量外键的表，这个检查的开销可以占到写入延迟的 30% 以上。

PG19 对外键约束检查进行了多项优化：

• 批量检查：将多个外键检查合并为一次操作
• 索引扫描优化：利用目标表索引的高效路径
• 缓存改进：减少重复的元数据查找

5.2 实测对比

用一个典型场景测试——订单表有 3 个外键引用（用户、产品、仓库）：

-- 创建测试表
CREATE TABLE users (id BIGINT PRIMARY KEY);
CREATE TABLE products (id BIGINT PRIMARY KEY);
CREATE TABLE warehouses (id BIGINT PRIMARY KEY);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT REFERENCES users(id),
    product_id BIGINT REFERENCES products(id),
    warehouse_id BIGINT REFERENCES warehouses(id),
    quantity INT,
    created_at TIMESTAMP DEFAULT now()
);

-- 插入 100 万条引用数据
INSERT INTO users SELECT generate_series(1, 100000);
INSERT INTO products SELECT generate_series(1, 50000);
INSERT INTO warehouses SELECT generate_series(1, 1000);

在 PG18 和 PG19 上分别执行批量插入：

-- 测试 10 万条订单插入
INSERT INTO orders (id, user_id, product_id, warehouse_id, quantity)
SELECT
    generate_series(1, 100000),
    (random() * 99999 + 1)::int,
    (random() * 49999 + 1)::int,
    (random() * 999 + 1)::int,
    (random() * 100 + 1)::int;

在典型硬件上，PG19 的外键检查耗时约为 PG18 的 60-70%，外键越多提升越明显。

5.3 设计建议

外键性能的提升不应该成为滥用外键的理由，但如果你之前因为性能考虑而放弃外键，现在可以重新考虑：

-- ✅ 推荐：核心业务约束用外键
ALTER TABLE orders ADD CONSTRAINT fk_user
    FOREIGN KEY (user_id) REFERENCES users(id);

-- ✅ 推荐：级联删除减少应用代码
ALTER TABLE orders ADD CONSTRAINT fk_user_cascade
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;

-- ⚠️ 谨慎：审计表的外键可能影响批量插入性能
-- 考虑在审计场景用应用层保证一致性

-- ❌ 不推荐：中间表的循环外键
-- 仍然应该避免设计上的循环依赖

六、在线数据校验和切换

6.1 过去的痛点

数据校验和（checksum）是检测底层存储损坏的关键防线。但在 PG18 及之前，切换校验和需要：

1. 停库
2. 运行 pg_checksums --enable 或 --disable（全库扫描）
3. 重启数据库

对于 24/7 运行的生产系统，这几乎不可能执行。很多团队因此放弃了校验和，直到真的遇到了静默数据损坏才后悔。

6.2 PG19 在线切换

-- 查看当前校验和状态
SHOW data_checksums;

-- 在线启用校验和（无需停库）
SELECT pg_enable_data_checksums();

-- 在线禁用校验和
SELECT pg_disable_data_checksums();

pg_enable_data_checksums() 会在后台启动一个 worker 进程，逐页计算并写入校验和。这个过程不会阻塞正常的读写操作，但会消耗额外的 I/O 资源。

6.3 监控进度

-- 查看校验和启用/禁用进度
SELECT * FROM pg_stat_progress_checksum;

输出包含已处理页数、总页数、预计剩余时间等信息。

6.4 生产环境最佳实践

-- 1. 先在低峰期启动（避免影响业务 I/O）
SELECT pg_enable_data_checksums();

-- 2. 监控 I/O 影响
SELECT * FROM pg_stat_progress_checksum;

-- 3. 如果 I/O 压力过大，可以暂停
SELECT pg_pause_data_checksums();

-- 4. 低峰期继续
SELECT pg_resume_data_checksums();

注意： 启用校验和后，每个 8KB 页面增加 8 字节的校验和字段。对于绝大多数场景，这个空间开销可以忽略。

七、TOAST 默认压缩改为 LZ4

7.1 什么是 TOAST

PostgreSQL 的行不能跨页存储（默认 8KB 页大小），当一行数据超过这个限制时，大字段会被"切片"存到 TOAST（The Oversized-Attribute Storage Technique）表中。

PG18 及之前，TOAST 默认使用 pglz 压缩算法。PG19 把默认值改为 lz4。

7.2 为什么换成 LZ4

对于大多数 OLTP 工作负载，LZ4 的解压速度远比压缩率重要——你读大字段的频率远高于写。

7.3 迁移影响

# PG19 新默认值
default_toast_compression = lz4

# 如果需要回退到 pglz
default_toast_compression = pglz

已有表不受影响——它们保持建表时的压缩方式。只有新创建的表才会使用 lz4。

如果你想迁移已有表：

-- 查看当前压缩方式
SELECT attname, attcompression
FROM pg_attribute
WHERE attrelid = 'my_table'::regclass AND attstorage != 'p';

-- 修改压缩方式（需要重写表）
ALTER TABLE my_table SET (toast_compression = 'lz4');
VACUUM FULL my_table;  -- 触发实际重写

注意： VACUUM FULL 会锁表。对于大表，建议在维护窗口执行，或使用 pg_repack 扩展。

八、JIT 默认关闭：承认并修正

PG19 做了一个"少见的诚实决定"：把 JIT（Just-In-Time 编译）默认关闭。

之前的默认行为是 jit = on，但 JIT 只在查询成本超过 jit_above_cost（默认 100000）时才激活。问题在于：这个成本估算不可靠。

实际场景中，JIT 编译的开销（LLVM 启动延迟）经常超过它带来的执行加速。特别是在短查询密集的 OLTP 场景，JIT 几乎没有正面收益。

# PG19 新默认
jit = off

# 如果你的工作负载确实受益于 JIT（大量分析查询）
jit = on
jit_above_cost = 500000   # 提高阈值，只对真正的大查询启用

建议： 除非你经过实测确认 JIT 对你的分析查询有实质帮助，否则保持关闭。JIT 不是性能问题的银弹，它的适用场景非常窄。

九、COPY FROM SIMD 加速

PG19 使用 SIMD CPU 指令加速 COPY FROM 的文本和 CSV 解析。这是一个零配置的透明优化。

9.1 性能提升

9.2 利用建议

如果你的 ETL 流程使用 COPY FROM 导入数据，升级到 PG19 后可以立即获得加速，无需任何代码修改。

对于特别大的导入场景（10GB+），建议组合使用：

-- 1. 导入前关闭同步提交
SET synchronous_commit = off;

-- 2. 增大 maintenance_work_mem
SET maintenance_work_mem = '2GB';

-- 3. 使用 COPY FROM 替代 INSERT 多行
\copy my_table FROM '/data/large_import.csv' WITH (FORMAT csv, HEADER true);

-- 4. 导入后手动 ANALYZE
ANALYZE my_table;

-- 5. 恢复同步提交
SET synchronous_commit = on;

十、NOTIFY 精准唤醒

10.1 过去的行为

PG18 及之前，NOTIFY 会唤醒几乎所有后端进程，即使它们没有监听对应的 channel。这导致了不必要的上下文切换和 CPU 唤醒。

10.2 PG19 的改进

现在 NOTIFY 只唤醒实际监听该 channel 的后端。

-- 只有监听 'order_events' 的连接会被唤醒
NOTIFY 'order_events', '{"order_id": 12345, "status": "shipped"}';

在大量使用 LISTEN/NOTIFY 的应用中（如实时通知、缓存失效），这个优化可以显著降低 CPU 使用率。

10.3 实测

在一个有 500 个连接、20 个 LISTEN channel 的测试中：

十一、查询扫描标记 All-Visible 页

11.1 背景知识

PostgreSQL 的可见性映射（Visibility Map）标记哪些数据页的所有行对所有事务可见。之前只有 VACUUM 和 COPY ... FREEZE 能设置这个标记。

PG19 让普通的查询表扫描也能标记 all-visible 页。这意味着：

• 索引扫描可以跳过可见性检查——对于大范围查询有显著加速
• VACUUM 的工作量减少——很多页已经被查询标记过了
• Autovacuum 触发频率可能降低——因为可见性映射更及时

11.2 实际影响

-- 对于只读或主要读取的工作负载，这个优化自动生效
-- 无需配置

-- 验证效果：查看可见性映射覆盖率
SELECT relname,
       pg_size_pretty(pg_relation_size(relid)) AS table_size,
       ROUND(100.0 * n_all_visible_pages / NULLIF(n_pages, 0), 1) AS visible_pct
FROM (
    SELECT relid,
           relpages AS n_pages,
           pg_stat_get_all_visible_pages(relid) AS n_all_visible_pages
    FROM pg_class
    WHERE relkind = 'r'
) t
JOIN pg_stat_user_tables USING (relid)
ORDER BY n_pages DESC
LIMIT 10;

十二、迁移注意事项

12.1 Breaking Changes 清单

从 PG18 升级到 PG19，以下不兼容变更需要提前处理：

1. MD5 密码将被警告

WARNING: MD5 password authentication is deprecated

解决方案：迁移到 SCRAM-SHA-256

-- 查看当前密码加密方式
SELECT rolname, rolpassword FROM pg_authid WHERE rolpassword LIKE 'md5%';

-- 重设密码（使用 SCRAM-SHA-256）
ALTER ROLE myuser PASSWORD 'new_password';

2. RADIUS 认证已移除

如果你的 pg_hba.conf 使用了 RADIUS 认证，升级前必须迁移到其他方式。

3. standard_conforming_strings 强制开启

不再支持反斜杠转义的非标准字符串。如果你的应用依赖 E'...' 或反斜杠转义：

-- ❌ 旧写法（不再工作）
SELECT E'hello\nworld';

-- ✅ 新写法
SELECT 'hello' || chr(10) || 'world';
-- 或使用标准转义
SELECT 'hello
world';

4. max_locks_per_transaction 默认值从 64 变为 128

由于锁大小分配方式变化，实际容量不变，但如果你的配置中显式设置了 max_locks_per_transaction = 64，需要翻倍为 128 才能维持相同容量。

5. 数据库/角色/表空间名称禁止换行符

这是安全修复。如果你的数据库中有包含 \r 或 \n 的名称，pg_upgrade 会拒绝升级。

-- 检查是否有问题名称
SELECT datname FROM pg_database WHERE datname ~ '[\r\n]';
SELECT rolname FROM pg_roles WHERE rolname ~ '[\r\n]';

6. JIT 默认关闭

如果经过测试确认你的工作负载受益于 JIT，需要显式启用：

jit = on

7. json_array() 空结果返回空数组而非 NULL

-- PG18：返回 NULL
-- PG19：返回 '[]'
SELECT json_array(SELECT 1 WHERE false);

12.2 升级流程建议

# 1. 在测试环境执行 pg_upgrade --check
pg_upgrade -b /usr/local/pgsql18/bin -B /usr/local/pgsql19/bin \
    -d /data/pg18 -D /data/pg19 --check

# 2. 处理所有检查报告的问题

# 3. 使用 pg_upgrade 执行升级（--link 模式更快）
pg_upgrade -b /usr/local/pgsql18/bin -B /usr/local/pgsql19/bin \
    -d /data/pg18 -D /data/pg19 --link

# 4. 升级后运行统计信息更新
vacuumdb --all --analyze-in-stages

# 5. 启用数据校验和
psql -c "SELECT pg_enable_data_checksums();"

十三、系统视图新增一览

PG19 新增了多个监控视图，值得关注：

-- 1. 锁统计：按锁类型查看
SELECT * FROM pg_stat_lock;

-- 2. 恢复状态：流复制监控
SELECT * FROM pg_stat_recovery;

-- 3. Autovacuum 评分：理解 vacuum 优先级
SELECT * FROM pg_stat_autovacuum_scores;

-- 4. 动态共享内存分配详情
SELECT * FROM pg_dsm_registry_allocations;

-- 5. Vacuum 进度增加发起者信息
SELECT relid, started_by, mode FROM pg_stat_progress_vacuum;

-- 6. 复制槽内存超限统计
SELECT slot_name, mem_exceeded_count FROM pg_stat_replication_slots;

十四、完整配置调优参考

以下是一个针对 PG19 生产环境的推荐配置模板（基于 64GB 内存、NVMe SSD、16 核的服务器）：

# === 内存 ===
shared_buffers = 16GB
effective_cache_size = 48GB
work_mem = 256MB
maintenance_work_mem = 2GB

# === 并行查询 ===
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# === Autovacuum ===
autovacuum_max_workers = 6
autovacuum_max_parallel_workers = 2
autovacuum_naptime = 30s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

# === 异步 I/O ===
io_method = worker
io_min_workers = 1
io_max_workers = 8
io_worker_idle_timeout = 300s

# === WAL ===
wal_level = replica
max_wal_size = 4GB
min_wal_size = 1GB
wal_compression = lz4

# === 连接 ===
max_connections = 200
password_expiration_warning_threshold = 7d

# === JIT ===
jit = off  # 除非实测有收益

# === TOAST ===
default_toast_compression = lz4  # PG19 新默认

# === 校验和 ===
# 升级后在线启用

十五、总结与升级决策

PostgreSQL 19 不是一次革命性的版本，但它是近年来最"实用主义"的版本之一。每一个主要特性都在解决真实的生产痛点：

• SQL/PGQ 降低了图形态查询的语法成本，但不试图替代专用图数据库——定位精准
• 并行 Autovacuum 让大表运维不再是噩梦——迟到但终于来了
• 在线校验和切换 解决了一个运维"不可能三角"——不停库、不丢数据、能检测损坏
• 外键性能提升 让"正确的数据模型"和"好的写入性能"不再矛盾
• LZ4 默认 TOAST 压缩 是一个"大家都想要但没人主动改"的优化
• JIT 默认关闭 是罕见的"承认之前判断有误"的决策——这种诚实比功能更重要

升级建议：

PG19 的 Beta 阶段预计持续 3-4 个月，正式版预计 2026 年 Q3-Q4 发布。现在是开始测试兼容性的最佳时机——特别是 SQL/PGQ，它可能改变你对"需不需要图数据库"这个问题的回答。