PostgreSQL 博览 RSS

大页把 TLB 覆盖的内存从 6MB 量级抬到 GB 量级，大幅减少 TLB 未命中。Christophe Pettus 给出完整步骤：用 shared_memory_size_in_huge_pages 算出需要多少页，96GB 缓冲池约需 49152 个 2MB 页；在内核命令行预留，再把 huge_pages 设为 on 而不是 try。透明大页设成 madvise 而非 always，启动后查 /proc/meminfo 核对。

Christophe Pettus 把两种湖仓路线摆在一起看。pg_lake 是 Snowflake 那一路，作为扩展直接在 Postgres 后端读写 Iceberg 表与对象存储文件，本质是外部数据包装器，查询时把 OLTP 与湖仓联邦起来。Lakebase 走 Databricks 这一路，把 Neon 的存算分离搬进湖仓，本身就是湖仓里的无服务器 Postgres。前者适合已有两套系统一起查，后者适合要写时复制分支的负载。

Shaun Thomas 说单实例多库撞到的往往不是硬件上限，而是共享资源。所有库抢同一份缓冲池，某个库扫 500GB 大表就会挤掉另一个库延迟敏感的热页；一个库疏于回收，事务 ID 回卷会让整个实例拒绝新事务；行级锁的 multixact 成员在实例级有 21GB 上限，一个库锁得凶就会拖住其他库；WAL 重放又是单线程，写入密集的主库产出速度可能结构性地超过副本的消化能力。他主张按库拆成独立实例。

表过了 5 亿行以后，连接带来的读放大和 CPU 开销会变成主要瓶颈。Jake Hertz 的做法是有选择地放弃范式：先用 pg_stat_statements 找出连接税落在哪些语句上，再把高频访问、低基数的元数据列迁进主表，把模式压平，省掉昂贵的连接；冗余出来的数据交给列式压缩处理。这样做减少了缓冲池压力和存储占用，把一个受 I/O 限制的系统变成 CPU 效率更高的系统。代价是写入侧要自己维护一致性。

自动扩缩容的托管数据库最常见的抱怨，是流量一涨账单跟着失控，而多数云厂商只在费用产生之后才发通知。Neon 新增组织级消费上限，让团队为 PostgreSQL 负载预先设定预算阈值，把成本控制从事后告警挪到事前拦截。对按需扩缩的用法来说，这条限制决定了扩容会不会一路跑到月底才被发现，预算与自动扩容的边界需要一起规划。

Christophe Pettus 回看异步 I/O 落地一年后的变化。PostgreSQL 19 新增四个参数，为 I/O 工作进程池设定上下限、空闲超时和启动间隔，让它像自动伸缩器：查询真的等 I/O 时扩容，闲下来就收缩。预读窗口随扫描规模放大，宽表扫描和索引范围扫描受益最明显；EXPLAIN ANALYZE 新增 IO 选项，可按节点查看异步 I/O 活动。他建议按 19 的默认值重新压测，把 18 上手调的进程数换成上下限。

Linux 7.0 在多个架构上删掉了 PREEMPT_NONE 抢占模式，默认改为 PREEMPT_FULL 或 PREEMPT_LAZY。AWS 的压测显示特定条件下 PostgreSQL 吞吐掉到 6.x 的 0.51 倍。Christophe Pettus 指出触发条件很窄：巨大的共享内存以小页映射、高并行度、工作集不断拉入新页面。打开 huge_pages 后次要缺页从约 3100 万降到约 120 次，可以照常升级内核。

storage_engine 是提供两种表访问方法的 PostgreSQL 扩展：colcompress 走列式压缩存储，支持向量化执行、chunk 级 min/max 裁剪、并行扫描和 MergeTree 式排序；rowcompress 走行式批量压缩，用删除位图实现 DELETE 与 UPDATE。作者给出的百万行串行测试里，聚合最高快 10 倍，数据体积缩小 3 到 5 倍。当前版本兼容 PostgreSQL 16 到 18。

EMS 发布数据库管理工具 SQL Management Studio for PostgreSQL 2.0。界面侧加入深色主题，并改进高 DPI 与大字号显示，在高分辨率屏幕上保持正确缩放；平台侧原生支持 Windows 11 ARM。安全方面，出站邮件通知支持 SSL/TLS 与 STARTTLS。日常运维新增任务导入导出，迁移或备份时可保存与恢复任务和调度配置，日志文件名也能按自定义日期时间格式生成。

Embodied Carbon Observatory 要分清工厂是真的减排，还是沾了电网变干净的光。Andrew Stebbins 把 4 万份环境产品声明和 EPA 二十多年的电网数据对齐，追踪全美 1.5 万个制造设施的碳强度轨迹，难点是两套更新频率完全不同的时序数据：EPD 不定期更新，电网数据按年发布。原本归因查询要 6 到 8 秒，撑不起交互式地图；改用 TimescaleDB 的超表与连续聚合后降到 100 毫秒以内。