PostgreSQL 博览 2026-04-21 RSS 订阅

PostgreSQL 19 给 REPACK 加了 CONCURRENTLY 选项：大部分时间只持较弱的共享更新排他锁，靠复制槽做逻辑解码追上并发改动，只在最后交换文件节点时短暂升为排他锁。depesz 在一张删掉 80% 行、19GB、两亿行的表上实测，66 秒压到 4.1GB，其间插入延迟从 1.5 毫秒升到平均 5.5 毫秒，峰值约 63 毫秒。已知限制是复制槽稀缺、全库同时只能跑一个 REPACK，末尾升锁还可能死锁。

Ring 把跨四大洲、1000 到 2000 亿条嵌入向量的语义视频搜索建在 RDS for PostgreSQL 和 pgvector 上，每天新增约 20 亿条，查询延迟压在 2 秒以内。按用户分区避免单张巨表；刻意不建向量索引，用暴力并行扫描换取 100% 召回；再用 16 个工作进程把 EBS 带宽吃满。Alexander Onbysh 说明选 PostgreSQL 而非专用向量库，考虑的是这个规模下的成本与运维经验。

PostgreSQL 调优里最容易混为一谈的，是慢查询与长耗时查询。Sonia Valeja 指出，慢查询因为缺索引、计划不佳或模式设计问题而超出预期地耗时，白白占用资源；长耗时查询处理的是大数据集或复杂运算，本身效率正常，只是活儿多。两者的处置方式不同：前者要加索引、更新统计信息，后者更多是调度和负载规划的问题。判断依据来自业务上下文，跑得久未必需要优化，先分清查询是效率低还是工作量大。

Christophe Pettus 把 pg_plan_advice 与 Oracle 式提示、pg_hint_plan 区分开：它提供的是机制而非策略，规划器仍握有最终决定权，建议只作为代价计算之外的参考，开发者可以只指定连接方法这类局部信息，其余交给规划器优化。补丁分成核心机制、采集示例和应用示例三个模块，第三方扩展可以自建存储与匹配策略。典型用法是找出慢查询，采集期望计划，再按 query id 存下建议，不必改应用 SQL。

pgEdge 把 PostgreSQL 的全生命周期收进一个轻量编排器，配置、网络、复制和高可用都通过声明式 REST API 管理，创建、故障切换、备份恢复与扩缩写在同一套规格里。Antony Pegg 演示的路径是先起 Docker Swarm，再启动控制平面容器，POST 一份定义三个节点及端口的 JSON，轮询到状态变为 available，约五分钟完成。节点间自动建立 Spock 复制，高可用交给 Patroni。