PostgreSQL 博览 RSS

Pavel Luzanov 梳理了 2025 年 11 月 CommitFest 进入 PostgreSQL 19 的改动。规划器方面有急切聚合、COUNT 优化和并行 TID Range Scan，分区表 COPY 也更快。新特性包括 error_on_null、符合 SQL 标准写法的临时对象函数，以及让副本等待主库位点的 WAIT FOR。监控侧新增复制槽内存计数器、缓冲区分布统计和单表统计重置时间。

PostgreSQL 的维护设计假设负载存在安静期，批量 ETL 之间会留出清理窗口。IoT 传感器、交易流和指标采集这类不间断写入抹平了窗口，于是三件事同时发生：autovacuum 一直在跑并与写入争抢 I/O，检查点在 WAL 里制造连续的整页写突发，ANALYZE 的统计更新也与摄入互相干扰。WAL 因此成为吞吐上限，按作者测算每次插入连同索引会产生 2.5–3.5KB 的 I/O。加 worker 或换更快的存储只能推迟问题。

PostgreSQL 社区协会（PGCA）是核心团队在 2011 年授权成立的非营利组织，负责持有并保护 PostgreSQL 的商标与品牌资产。协会参考其他开源基金会的赞助模式，考虑到维护品牌资产的成本上升，自 2026 年 2 月 1 日起上调 Benefactor 与 Patron 两个最高等级的赞助额度，其余等级维持不变。同期上线改版后的官网，把非营利使命、商标使用规范和捐赠入口集中呈现，域名仍是 postgres.ca。

软删除表的常见写法是 EXISTS 配活跃行的部分索引。Nikolay Samokhvalov 对比两个等价查询：一个用 EXISTS 匹配占 98% 的活跃帖子，另一个把 not 挪进子句，用 NOT EXISTS 匹配占 2% 的已删除帖子。后者快 32 倍。原因是索引里「没找到」可以完全跳过堆访问，而「找到了」在频繁更新的表上还要回表校验可见性：前者做了 52.7 万次堆读取，后者 1 万次。凡少数派布尔标记的模式都适用这个思路。

Matty Stratton 从写放大的角度解释索引为何反噬写入：一张带 5 个索引的表每插入一行要落 6 次写，1 次堆写加 5 次索引写，在 5 万行每秒的摄入速率下就是每秒 30 万次写，带来大量 I/O 与 WAL 膨胀。时间戳这类单调递增列还有「热右边缘」问题，B-tree 最右侧叶页持续分裂。由此形成回路：索引拖慢写入，缓冲区压力上升，查询变慢，于是再加索引。每秒 500 行时无碍的索引数量，到 5 万行每秒就成了问题。

Lukas Fittl 反对把 AI 包装成 DBA 的替代品。他认为这种说法混淆了「执行工作」与「对结果负责」两件事，生产出问题时模型无法担责，团队反而留下一段责任真空。他主张换个方向用 AI：不去替换数据库专家，而是由平台团队提供安全、经过筛选的 AI 工具，帮应用工程师和数据平台团队更有效地使用数据库。LLM 擅长的是检索资料、交叉引用代码、弥合团队之间的知识差距，生产决策的归属和问责仍要落在人身上。