PostgreSQL 社区周报（第 1 期）

2026 年 10 月，Postgres 社区周报 第 1 期，本周新闻速递。

目录

用 PostgreSQL 搞定一切

• 作者自 2003 年起使用 PostgreSQL，认为其核心优势是：稳定可靠、易安装运维和扩展、能大幅简化 IT 架构。
• PostgreSQL 历史悠久、社区活跃，持续加入 JSON、分区、CTE 等现代功能，同时保持兼容与稳定。
• 可替代独立全文搜索系统（如 Solr/Elastic）：内置 tsvector/tsquery，必要时可用 pg_textsearch、ParadeDB/pg_search 等扩展实现 BM25 和高级搜索。
• 可替代 MongoDB：JSON/JSONB 加 GIN 索引，支持高效存储与查询。
• 可替代 Kafka/RabbitMQ 等队列系统：利用 SELECT ... FOR UPDATE、SKIP LOCKED 将表用作队列。
• 可替代 ClickHouse 处理高吞吐时间序列数据：通过 TimescaleDB 扩展。
• 可作为 AI 向量数据库：pgvector、pgai 支持向量检索和 LLM 工作流。
• 可替代 Redis 做缓存：使用 UNLOGGED 表，并可用触发器模拟过期。
• 还可用于存储原始二进制数据、用 LTREE 管理层级数据、用 Apache AGE 做图数据库，甚至通过 SQL 直接返回 JSON 替代部分微服务。
• 核心建议：优先问“PostgreSQL 能不能做？”，先用 PostgreSQL 起步，只有真正遇到性能或功能瓶颈时再引入专用系统。

深入阅读

PostgreSQL 19：有哪些变化、哪些重要、现在该测试什么

• 发布节奏与定位：PostgreSQL 19 已进入候选版本阶段，计划 RC2 于 11 月 12 日、正式版于 11 月 19 日发布；在正式 GA 前，生产环境仍应以 PostgreSQL 18 为目标，19 应先在非生产环境测试。
• 可靠性优先：多个重要功能因开发/审查不足被回退，包括 SQL 属性图查询、分区合并/拆分、运行时启停数据校验和、GROUP BY ALL、UPDATE/DELETE ... FOR PORTION OF 等，体现社区“可靠性优先、发布节奏可预测”的原则。
• 审查压力上升：AI 辅助审查更快发现边缘案例和安全问题，但关键是项目是否有足够能力调查、修复和审查这些问题。
• REPACK / REPACK CONCURRENTLY：可重写表以回收空间、按索引重组行，并发模式下大部分过程可继续读写；但最终切换仍需 ACCESS EXCLUSIVE 锁，需要临时磁盘空间，并需注意旧快照的可见性行为。应结合实际写入和长事务测试。
• 查询计划建议：pg_plan_advice 和 pg_stash_advice 可描述、复现并约束连接顺序、扫描方式等计划选择，用于应对计划回归；但它不是通用性能开关，过度约束可能妨碍优化器随数据变化选择更优计划。
• Autovacuum 改进：支持索引清理等阶段使用并行 worker，并引入评分机制和 pg_stat_autovacuum_scores 视图来优先处理更需要的维护任务；这是有目标的并行，不是所有阶段全并行。测试应关注维护是否跟得上、对应用延迟和资源的影响。
• 逻辑复制序列同步：可将 publisher 的序列值同步到 subscriber，支持初始同步和 ALTER SUBSCRIPTION ... REFRESH SEQUENCES；但 publisher 必须是 PostgreSQL 19+，且不是持续同步，序列值仍可能再次不一致，需演练切换流程。
• 其他值得关注功能：ON CONFLICT DO SELECT 让 upsert 返回已存在行；窗口函数支持 IGNORE NULLS。
• 兼容性与默认值：PostgreSQL 19 默认禁用 JIT 编译，依赖 JIT 的分析型负载应显式评估该设置。
• 测试建议：搭建反映真实部署的非生产环境，覆盖查询、扩展、驱动、数据分布、维护流程，并包含升级与恢复演练；RC 仍是测试版本，不是生产推荐，应积极反馈回归问题。

深入阅读

PostgreSQL 19 因 AI 代码审查发现更多缺陷而延期

• PostgreSQL 19 发布时间从原定 9 月底/10 月初推迟到约 11 月 19 日，另有 8 至 10 项重要功能被撤回或推迟到 PostgreSQL 20。
• 延期部分原因是 LLM 辅助代码审查更快发现了大量边缘案例缺陷；虽然单个修复可能很小，但逐项处理有固定开销，最终导致时间不足。
• 一些被撤回功能存在重大架构缺陷，难以在 beta 阶段“快速修复”；AI 审查也提高了功能写完后才被审视的质量门槛。
• 开发者强调，这不是“vibe coding”导致的，因为多数新功能编写时该方式尚不可用。
• 被移除的功能包括 SQL/PGQ 支持；贡献者 Tom Lane 曾警告，若在 v19 发布，可能出现直到 v20 才能修复的发布后缺陷。
• 尽管延期，PostgreSQL 19 仍被承诺为“很棒的版本”，包含可避免 VACUUM FULL 表锁的 REPACK CONCURRENTLY，并会因额外审查而更稳健。
• 被撤回功能可能进入 PostgreSQL 20；PG20 原预计只修 bug，现在可能承载这些新功能。

深入阅读

Postgres 并不慢，慢的是你的存储

• 核心观点：Postgres 扩展性问题常被误判为数据库慢，实际可能是存储达到带宽、IOPS 或队列上限，导致查询、WAL、checkpoint、VACUUM、逻辑复制互相争抢资源。
• 五类典型症状：更新/写入变慢、P95 读延迟不稳定、autovacuum 落后与表膨胀、checkpoint 变慢并干扰业务、逻辑复制积压。
• 基准测试：同一 3.3B 行、482 GiB 的 pgbench 随机 UPDATE 负载，64 客户端；对比 gp3 EBS 3000 IOPS 与本地 NVMe。NVMe 中位 16,030 TPS，EBS 1,734 TPS，约 9.24 倍；事务延迟 4.0 ms vs 36.9 ms。
• 维护操作对比：清理 10 GB 膨胀，VACUUM 为 366 秒 vs 964 秒；清空 10 GB 逻辑复制积压为 139 秒 vs 238 秒。
• 差距来源：EBS 主要耗在等存储：页读取约 19 ms vs 0.3 ms，WAL fsync 约 11 ms vs 1.5 ms；CPU 工作相近，约 2 ms。EBS 更多会话等待 I/O，CPU 更多时间处于等待状态。
• 持久性方案：本地 NVMe 单机数据随节点丢失，因此持久性需放在集群层：双 standby + quorum 同步复制（如 ANY 1，跨 AZ），并用 WAL-G 等做基础备份与连续 WAL 归档到对象存储。
• 生产架构：NVMe 提供性能，复制提供可用性，独立备份 + 归档 WAL 提供恢复能力；备份应放在独立故障域，必要时做区域副本，目标 RPO 可达秒级并支持 PITR。
• 结论：Postgres 疑似停止扩展时，应同时诊断数据库与存储；本地 NVMe 能显著降低存储受限负载的 I/O 惩罚，但需要不同的运维模型和高可用/备份恢复架构。

深入阅读

训练 4B 模型生成比 Postgres 快 81% 的查询计划

• 核心目标：用小型开源4B模型通过监督微调（SFT）和智能体强化学习（RL）生成 pg_hint_plan 提示，引导Postgres选择更优查询计划；重点不是替代优化器，而是优化反复执行的分析型查询。
• 初始模型表现很差：在113条JOB查询中，有99条无法生成查询计划，且不熟悉工具调用和智能体框架。
• 方法上构建了 qo-agent 工具链，包括查看表结构、列统计、获取计划、评估候选、保留默认计划、结束搜索；用CEB训练、JOB验证，并做查询拓扑去重以避免模板泄漏。
• 测量降噪是关键：使用4个Postgres容器、2GB shared_buffers、4MB work_mem、预热和交错测量候选/默认计划；自定义“fooling rate”评估噪声，使no-op误差约降4倍，p90查询几乎不再被噪声误导。
• 先用约500条GPT-6 Astra智能体轨迹做离线蒸馏/SFT，让4B模型学会工具调用和计划表达；2个epoch有提升，3个epoch反而退化，说明验证loss平稳不代表没有学到有用行为。
• RL阶段设计了裁剪、软阈值、默认计划惩罚等奖励机制，并用自定义“anchored GRPO”处理噪声环境和相对优势；训练/推理在2×H100上，Postgres测量在本机，通过Tailscale连接。
• 最终结果：在JOB上采用最佳-of-15（每查询3次rollout）达到1.81倍几何平均加速和1.81倍总工作负载加速；113条join-heavy查询总延迟降低44.7%。
• 成本约1200美元：约800美元用于租用2×H100约95小时，约400美元用于OpenAI API生成教师轨迹；代码开源。
• 结论：小模型结合领域RL环境可在特定数据库和重复查询场景中显著优于Postgres默认计划；前沿大模型仍是强教师；企业可用自有数据低成本训练小模型。下一步包括Bao式hint sweeping、on-policy distillation、trace inversion和EC2噪声测量。

深入阅读

让 Postgres 分析性能提升 300 倍：批处理、算子融合与 SIMD

• pgrust 0.2 主打性能：比上一版快 10 倍；OLTP 基准比 Postgres 快 30%；在 ClickBench 分析型基准上比 Postgres 快 300 倍，甚至领先 ClickHouse。
• 查询引擎优化是 300 倍提升中的关键，单独贡献约 10 倍；核心目标是减少 CPU 和内存带宽开销。
• Postgres 诞生于磁盘 I/O 为主要瓶颈的时代；如今数据常驻内存、NVMe 更快、分析负载更偏向批量扫描，CPU/内存效率变得更重要。
• 示例中 Postgres 对 5 亿个浮点数求和约需 20 秒，而等效 Rust 循环约 358ms，说明查询引擎层有巨大优化空间。
• Postgres 的 Volcano 模型逐行调用 next()，开销大；改为批处理后可显著减少函数调用和流水线损失。
• 算子融合把常见相邻操作合并成单一节点，避免中间拷贝；SIMD 进一步并行处理多行数据。
• 微型查询引擎优化效果：Volcano 模型 1.3s → 批处理 480ms → 算子融合 358ms → SIMD 135ms，累计约 9.6 倍提升。
• 算子融合适合硬编码常见模式，通用化需要 JIT；SIMD 对浮点求和需注意结果顺序和精度差异。

深入阅读

Postgres 的 recovery_prefetch 被认为有害并会导致服务中断

• 核心结论：recovery_prefetch 在开启 FPW/FPI 且使用同步复制的生产环境中，可能把副本拖慢到数小时，并进一步导致主库写入挂起甚至业务中断。
• 早期隐患未被重视：2021 年已有人提出“对已预取或已由 WAL FPI 加载的块继续预取”可能有问题，但当时被认为影响不大；2025 年现场报告显示备用库出现数小时回放延迟，禁用 recovery_prefetch 后恢复。
• 问题机制一：FPI 场景下做无用预取：预取代码未充分考虑共享缓冲区可能已从 WAL FPI 加载，却仍发出 fadvise，造成不必要的 I/O。
• 问题机制二：IOPS 放大：主库的大顺序 I/O 在副本上可能被 recovery_prefetch 转成 8KB 随机读，相同读取字节数下 IOPS 可放大至 16 倍，容易打满副本磁盘 IOPS。
• 与同步复制叠加会放大为宕机风险：同步复制要求至少一个健康备库，否则主库不能接受写入；当备库因 I/O 放大严重落后，且流复制连接中断时，备库会进入 WAL 恢复状态，直到追平才恢复流式复制。
• 可稳定复现：在小规格云盘、约 10GB pgbench 数据、更新 5% 表数据后杀掉 walreceiver，可观察到 TPS 归零、写入挂起 30 分钟以上；表更大时可挂起数小时。
• 关闭 recovery_prefetch 的效果：保持 FPW 开启但禁用 recovery_prefetch 后，不再出现长时间停顿和读 IOPS 爆发，备库基本能跟上，5% 更新可在 10 分钟内完成。
• 建议：作者倾向全面禁用 recovery_prefetch，认为在 FPW 默认开启时其收益可疑；同时建议考虑“两个备库 + quorum commit（ANY 1）”以提高同步复制架构的健壮性。

深入阅读