PostgreSQL 博览 2026-04-29 RSS 订阅

PostgreSQL 19 内置的 REPACK 把 VACUUM FULL、CLUSTER 和外部扩展 pg_repack 的活儿收拢到一条命令。Christophe Pettus 说 pg_repack 不会明天过时，但已在倒计时。加 CONCURRENTLY 后靠逻辑解码免去全程排他锁，他测得重建期间插入平均 5.5 毫秒、峰值 63 毫秒。未了的还有并发执行要占复制槽、压缩 TOAST 仍有损坏场景，他建议等 Beta 1。

PostgreSQL 18 的 io_workers 是个静态池，默认 3、上限 32，启动时定好就跟不上负载变化。19 把这一个旋钮换成四个可动态调整的参数，池子按队列深度伸缩，空闲进程会退休。io_method 仍是三选一：sync 传统路径、worker 各平台通用、io_uring 在 Linux 上更快但可用性有限。Christophe Pettus 提醒这套只覆盖读取，WAL 与共享缓冲区的写入仍是同步的。

Alexandra Wang 提交了连接统计的正式补丁，接续她一月的概念验证，并吸收了多位审阅者的意见。这一版改用基于索引的连接采样，目录结构复用现有 MCV 字段并新增三个可空列，支持完整的 JOIN 语法；能力范围仍限于等值连接、两表连接和 MCV 统计。在 Join Order Benchmark 上，基数估计的几何平均 q-error 从 103.4 倍降到 4.2 倍，执行时间热启动快 1.54 倍、冷启动快 1.37 倍。

Matty Stratton 把数据库性能问题分成两类：优化问题改一次就长期有效，架构问题改完还会随数据增长再冒出来。配置不当、缺索引、写法低效属于前者；行存要读进用不上的列、写入型数据的 MVCC 开销、不断上涨的维护成本属于后者，大容量高写入叠加分析查询时尤其明显。判别方法是看修复的有效期：每次见效的时间越来越短，说明撞的是架构约束。他给出的解法是 TimescaleDB 的行列混合存储、自动时间分区与连续聚合。

DBeaver 背后是 PostgreSQL JDBC 驱动，连接时不会自动跟随服务端时区，默认按客户机本地时区解释和显示。服务端跑 UTC 而客户端在别的时区时，timestamptz 的显示就会和服务端对不上，跨地域复制环境尤其容易踩到。Dave Stokes 给了两条改法：在偏好设置的界面时区里选 UTC 后重启，或在连接的驱动属性里加上 serverTimezone 设为 UTC。