PostgreSQL 博览 2026-05-24 RSS 订阅

Radim Marek 讲清了 TOAST 的机制：堆元组必须放进 8KB 页，超过约 2032 字节就触发瘦身，先压缩 EXTENDED 列，再把值挪到伴生的 TOAST 表，每块约 2000 字节，压缩可选 pglz 或 lz4。实用结论有几条：SELECT * 会把宽列全部解 TOAST；pg_column_size() 只读指针很便宜，length() 却要完整解压；改一个 1MB 的 jsonb 会重写全部分块。

Andrei Lepikhov 讨论 ORM 常见的多态关联：一列要指向多张互不相关的表，通常用类型加 id 的判别式外键，再用一串带类型条件的 LEFT JOIN 还原。问题出在规划器：连接链上的选择率误差会逐级相乘放大，当 join_collapse_limit 被突破、EXISTS 子查询没能放到合适位置时，基表行要走完整条 LEFT JOIN 链才被过滤。作者说这篇先界定问题，后续再给优化器改法。

Christophe Pettus 的 GUC 系列讲到 client_encoding：它声明客户端使用的字符编码，默认跟随服务端编码。两端不一致时，来往的每个字符都要过一次转换表，目标编码放不下某个字符就直接报错。常见的三类麻烦是默认值不匹配导致老数据报错、SQL_ASCII 库完全关掉编码校验，以及跨编码的转储恢复。他的建议是别在服务端配置里设它，交给 libpq 协商，确需非 UTF-8 编码时在连接串或角色级别指定。

Christophe Pettus 更正了此前关于 Snowflake Postgres 的推断：它就是社区版 PostgreSQL，不是带专有存储层的分支，之前对 table access methods 的猜测也不成立。更正本身的价值在于提醒读者，号称 Postgres 兼容的产品差别极大：有的是真 PostgreSQL，有的只是协议兼容，有的是分支。评估时应问清版本来源、扩展支持、系统目录行为、WAL 与备份语义和迁移退出路径。

有人提议把 PostgreSQL 的版本号从顺序编号改为年份，比如 19 改叫 2026。Tom Lane 反对，认为这会给发布计划套上不必要的约束：原定 2027 年发布的版本若延到 2028，后面的周期都会被打乱。Peter Eisentraut 补充说，很多产品在某年年底发布却按下一年的版本号做营销，年份并不能消除歧义。Philip Alger 则担心 12 月发布的版本几周后就显得过时，用户会因版本号的年代感而非实际需要去升级。

ClickHouse 把 Rust 写的 Delta Kernel 集成进来，用于读取 Delta Lake 表。湖仓格式的难点不在读 parquet，而在事务日志、schema 演进、版本语义和写入一致性；各引擎各自实现协议容易产生偏差，直接接入共享 kernel 能减少这类分歧。对用 ClickHouse 查询 Delta Lake 的团队，值得关注新实现的兼容性与性能差异，写入、时间旅行和 schema 演进最好单独压测。

GitHub 让 npm 的 staged publishing 正式可用，并新增安装期的来源控制选项。改动针对的是发布与安装的安全模型，而不是某个具体漏洞：staged publishing 把发布前的验证前置，来源白名单则限制本地路径、git URL、link 等安装方式被滥用。发布 npm 包的团队可以把它加进发布清单，JavaScript 项目可以在 CI 里收紧安装来源策略。