PostgreSQL 博览 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。

更新一行就要改所有索引，是 PostgreSQL 写放大的主要来源，HOT 更新是它的逃生口。Radim Marek 梳理触发条件：新元组要放得进同一页面，且被修改的列都没有索引，缺一不可。写多的表可以把 fillfactor 从默认的 100 降到 80 到 90，给 HOT 链留空间，代价是多占存储。效果看 pg_stat_user_tables 里 HOT 更新数与总更新数的比值，比例下滑就该查。长事务会阻止页面裁剪。

Christophe Pettus 开了个托管 Postgres 评测系列，第一篇给 Amazon RDS。长处是它十多年来一直能用，与 AWS 生态整合广，蓝绿部署让大版本升级不再吓人。短处集中在自主权：扩展版本滞后，plpython3u 一类根本没有；没有真正的超级用户；存储只能加不能减；单备机的 Multi-AZ 走块复制，备机不可读。他的结论是已在 AWS、负载中等、没有专职 DBA 的团队最合适。