PGConf.dev 2026：温哥华一周，Postgres 走向何方

预计阅读时间：9 分钟

从渥太华到温哥华，PGCon 换了城市也换了气质。今年新增的周二社区讨论日，让整周的信息密度翻了一倍。但真正值得记录的，不是海堤骑行或蒸汽钟，而是会场里那些直接影响 Postgres 未来走向的讨论和决策。

图查询：SQL/PGQ 刚落地，人群已经涌来

SQL/PGQ 是 PG 17 新提交的特性，让 Postgres 可以用标准 SQL 语法做图模式匹配。作者原本预期讨论会只有十几人，结果超过 25 人到场并积极参与辩论——这说明图查询在 Postgres 生态里的需求远比想象中旺盛。

SQL/PGQ 的核心思路是：先定义图模式（哪些表做顶点、哪些外键做边），再用 GRAPH_TABLE 在 SQL 内做路径遍历。下面是一个可以直接在 PG 17+ 上运行的最小示例：

-- 1. 创建基础数据
CREATE TABLE persons (
  id   BIGINT PRIMARY KEY,
  name TEXT
);

CREATE TABLE friendships (
  person1 BIGINT REFERENCES persons(id),
  person2 BIGINT REFERENCES persons(id),
  since   DATE
);

INSERT INTO persons VALUES
  (1, 'Alice'), (2, 'Bob'), (3, 'Carol'), (4, 'Dave');

INSERT INTO friendships VALUES
  (1, 2, '2024-01-01'),
  (2, 3, '2024-03-15'),
  (3, 4, '2024-06-01'),
  (1, 3, '2024-02-10');

-- 2. 创建属性图
CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (
    persons
  )
  EDGE TABLES (
    friendships
      SOURCE KEY (person1) REFERENCES persons(id)
      TARGET KEY (person2) REFERENCES persons(id)
  );

-- 3. 查询：找到 Alice 的朋友的朋友（两跳路径，不含 Alice 自身）
SELECT *
FROM GRAPH_TABLE (social_graph
  MATCH (a IS persons WHERE a.name = 'Alice')
        -[e1 IS friendships]-> (b IS persons)
        -[e2 IS friendships]-> (c IS persons)
  WHERE a.id <> c.id
  COLUMNS (
    a.name AS from_name,
    b.name AS via_name,
    c.name AS to_name
  )
);

预期输出：

from_name	via_name	to_name
Alice	Bob	Carol
Alice	Bob	Dave
Alice	Carol	Dave

注意：SQL/PGQ 在 PG 17 中刚提交，部分语法细节可能随版本微调。运行前请确认你的 PG 版本 ≥ 17，且 sql_pgq 扩展已启用。与 Apache/AGE 的路线之争也在讨论中——AGE 走 Cypher 风格，PGQ 走 SQL 标准路线，两者互补而非替代。

逻辑复制与多线程：两块难啃的骨头

逻辑复制过去十年进步巨大，但讨论揭示了几块明显缺口：DDL 复制、多租户/多数据库集群下的复制协调，以及高吞吐 OLAP 场景下的稳定性。结论很务实——当前逻辑复制还不能直接扛住大规模分析负载，缺件尚需补齐。

多线程改造的比喻很到位：给大象换上美洲狮的心脏，指望它跑得快。把 Postgres 从进程模型改成线程模型，牵动的是内存管理、信号处理、错误隔离等底层骨架。好消息是社区最顶尖的一批人正在协作推进，坏消息是这不会在短期内落地。如果你在架构决策中依赖"Postgres 将很快变多线程"这个前提，现在还不到下注的时候。

共享缓冲区热调整：从补丁到设计共识

这是本次会议最实际的进展之一。作者提出的"不重启即可调整 shared_buffers"补丁，已经被 Databricks 的 Heikki、David、Houyu 等人重基到 PG 18 的私有分支上，效果积极。更关键的是，双方在会场上快速达成了设计协作共识——因为 PG 19 中共享内存管理代码已经被重构过，地基已经打好。

这类改动在邮件列表上争论几个月未必能对齐，面对面半小时就敲定了方向。这就是线下会议的价值。

当前 PG 的 shared_buffers 只能通过修改 postgresql.conf 后重启生效。如果热调整最终合入，运维场景会显著简化：

# 当前方式：必须重启
pg_ctl -D /var/lib/postgresql/data reload   # 只能改不需要重启的参数
# shared_buffers 改完必须：
pg_ctl -D /var/lib/postgresql/data restart   # 业务中断

# 未来（假设热调整合入后）：
psql -c "ALTER SYSTEM SET shared_buffers = '4GB';"
psql -c "SELECT pg_reload_conf();"           # 无需重启，缓冲区动态伸缩

上面第二条是假设性示例，具体语法取决于最终实现。但方向明确：让 DBA 在负载波动时不用计划停机窗口来调缓冲区大小。

SQL 标准解读：从天书到可读

Peter Eisentraut 和 Vik Fearing（社区里两位 SQL 标准委员会成员）办了一场解读工作坊。SQL 标准的文风偏学术、密度极高，自己啃很容易迷失。Peter 把结构拆开讲完后，作者甚至大胆地向标准委员会提了自己的增强建议。

如果你需要查阅 SQL 标准原文，一个实用入口是 ISO 网站上的可购买草案，但更便捷的路径是社区维护的 wiki 和 Peter 的标准解读笔记。对于日常开发，关注 information_schema 和标准兼容性测试套件就够了：

-- 快速检查你的 PG 实例对 SQL 标准特性的支持程度
SELECT feature_id, feature_name, is_supported, subfeature_id
FROM information_schema.sql_features
WHERE is_supported = 'YES'
ORDER BY feature_id
LIMIT 20;

这条查询在任何 PG 版本上都能跑，输出当前实例已支持的标准特性清单，是排查兼容性问题的起点。

补丁评审面板：文明讨论的示范

今年的实时补丁评审面板是意外之喜。作者做好了迎接激烈反对的准备，结果看到的是耐心拆解利弊、为每个提案勾勒推进路径。这不是说所有提案都会合入，而是评审过程从"投票式否决"转向了"建设性打磨"。社区文化的这种演进，比任何单一特性都更值得关注。

三十年回望：朴素的人，宏大的结果

最后的重头戏是"30 Years of PostgreSQL"回顾面板，请回了最初的核心委员会成员。技术内容反而是次要的——真正打动人的是那种感觉：三十年前，没有人起步时想着"我们要造世界上最先进的开源对象关系数据库"。几十年后，他们的集体工作却触及了数十亿人的生活。

朴素的人做专注的事，最终成就宏大——这大概是开源最持久的动力来源。

离场清单

会议密集的一周，几条可带走的判断：

SQL/PGQ 可上手试了——PG 17 已合入，图查询场景先跑小规模验证，别急着在生产替换专用图数据库。
逻辑复制用于 OLAP 还要等——DDL 复制和多租户场景的缺口是硬约束，架构选型时不要过度承诺。
shared_buffers 热调整值得跟踪——PG 19 的内存管理重构是地基，PG 18 分支已有初步验证，关注 hackers 邮件列表的后续设计文档。
多线程改造是远期变量——短期架构决策不应依赖它。
线下对话的效率远超邮件列表——如果你在推一个复杂补丁，想办法和关键评审人坐到同一张桌子前。

温哥华再见，直到下一次。