PostgreSQL 技术日报 (4月1日)|pg_textsearch 1.0 发布及内核优化进展
🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态

⚙️ PostgreSQL技术文章
🧩 代理困境:为什么我的 Postgres 控制平面需要保持确定性

这篇文章反对在 PostgreSQL 核心控制平面操作中使用 AI 代理,比如扩容和故障转移。作者主张将这些关键任务保留在确定性的策略驱动自动化系统中,而不是交给概率性的 AI 系统。虽然 AI 代理正在广泛应用,但文章认为它们更适合在 PostgreSQL 环境中承担分析、分类和建议等任务。主要担忧是概率系统可能在关键数据库操作中引入不可预测性,而这些操作需要可靠且可重复的结果。
🧩 EDB Postgres AI Factory 新一代平台:为 Agent 时代而生

EDB 发布了新一代 Postgres AI Factory 平台,旨在帮助企业将 AI 代理部署到生产环境中。更新后的平台包含基于 Langflow 重构的 Agent Studio,简化了代理开发流程,通过 VectorChord 增强了向量基础设施以提升性能,并加强了安全的企业级 AI 部署能力。该平台专注于让组织能够基于自己控制的数据构建 AI 代理,解决了概念验证演示与生产就绪 AI 系统之间的差距。
https://www.enterprisedb.com/blog/next-generation-edb-postgres-ai-factory-built-agent-era
🧩 WarehousePG 为何用单集群胜任分析数据库多集群的工作

EDB Postgres AI for WarehousePG 提供了基于 PostgreSQL 的 MPP(大规模并行处理)架构,能够用单个集群处理高并发 BI 工作负载,这与需要多个集群和自动扩展的传统云数据仓库形成对比。该方案解决了基于消费的数据仓库中成本预测性问题,在这类系统中日常查询会产生难以预料的费用。通过采用基于容量的模型而非自动扩展方式,WarehousePG 以更低成本提供稳定性能,同时支持现代 BI 需求、AI 驱动的查询以及数据主权要求。这种方法消除了为分析工作负载管理多个集群的复杂性和成本开销。
https://www.enterprisedb.com/blog/edb-pg-ai-for-warehousepg
🧩 EDB Postgres® AI 2026年Q1版本发布亮点

EDB 在 2026 年第一季度发布的 Postgres AI 版本为企业用户带来了分析、AI 开发和平台运维方面的重要增强功能。主要改进包括 WarehousePG 的性能提升并通过基准测试验证、实时运营数据分析加速,以及向量数据库和 AI 代理功能的增强。此次更新还提供了新的管理功能,提升了系统韧性、自动化能力和数据主权控制,为企业环境中生产就绪的代理 AI 应用提供支持。
https://www.enterprisedb.com/blog/edb-postgres-ai-q1-2026-release-highlights
🧩 pg_textsearch 1.0:在 Postgres Pages 上构建 BM25 搜索引擎的方法

TigerData 发布了 pg_textsearch 1.0,这是一个直接构建在 PostgreSQL 存储层上的原生 BM25 搜索引擎。与 PostgreSQL 内置的 ts_rank 缺乏逆文档频率和词频饱和度不同,pg_textsearch 实现了真正的 BM25 评分,并采用 Block-Max WAND 优化来高效处理 top-k 查询。该扩展使用 LSM-tree 架构,内存中的 memtable 会溢出到磁盘段,全部存储在标准的 PostgreSQL 页面中。在 MS-MARCO 数据集上的基准测试显示,对于 2-4 个词的查询,性能比 ParadeDB 快 2.4-6.5 倍,并发吞吐量高出 8.7 倍。系统支持并行索引构建、SIMD 加速压缩,以及完整的 PostgreSQL 集成,包括 WAL、复制和 VACUUM。当前限制包括不支持短语查询、仅支持 OR 语义,以及缺乏后台压缩功能。
https://www.tigerdata.com/blog/pg-textsearch-bm25-full-text-search-postgres
📨 PostgreSQL Hacker 电子邮件讨论精选
🧩 关于 REPACK [concurrently] 的讨论
讨论的焦点是 REPACK CONCURRENTLY 功能中的锁冲突处理问题。Srinath 测试了 Alvaro 的死锁检测器方案,该方案能够成功处理查询等待 REPACK 操作的情况。然而,仍存在一个相反的问题场景:当现有事务持有冲突锁(如 SELECT 语句的 AccessShareLock)阻止 REPACK 最终的 AccessExclusiveLock 升级时,由于不存在循环等待,死锁检测器不会触发。REPACK 只是等待,达到锁超时后中止,浪费了可能数小时或数天的工作。Srinath 提议在最终交换阶段主动取消冲突会话,类似于 ResolveRecoveryConflictWithLock 的做法。Alvaro 同意这种方法可能是合适的,强调 REPACK 的工作通常很关键,不应该丢失。Antonin 质疑为什么用户要在运行 REPACK 前设置非零的锁超时。
🧩 减少 WAL 日志:移除 xl_heap_visible 记录(并最终改为访问时设置 VM)
Melanie Plageman已经提交了消除xl_heap_visible WAL记录的补丁,用于减少预写日志的开销。David Rowley审查了最终版本(v48-0001),并提出了一个小建议:在standard_planner()中填充Bitmapsets时,应该使用foreach_int()和foreach_node()而不是通用的foreach()循环。Melanie承认了这个疏漏并提供了后续补丁来修复已提交的代码。由于代码已经合并到主分支,David建议在当前功能冻结结束后,对整个代码库中类似的foreach()使用模式进行更全面的清理,特别是针对版本19中引入的代码变更。Melanie同意了这个建议,并将这项更广泛的清理任务添加到她的冻结后待办清单中。
🧩 缓冲区锁定的特殊性(提示、校验和、异步 I/O 写入)
在Andres Freund完成缓冲区锁定项目后,Yura Sokolov在PinBuffer函数中发现了一个竞态条件问题。该问题出现在等待缓冲区解锁之前检查skip_if_not_valid时——在等待期间缓冲区可能变为无效状态,因此有效性检查应该在WaitBufHdrUnlocked()之后进行。Andres同意这是错误的,并建议添加continue语句来重启循环,而不是移动检查位置。Yura还质疑是否仍需要等待缓冲区解锁,因为UnlockBufHdr现在使用了适当的原子操作。Andres确认仍需要等待,因为某些代码依赖于在阻止新pin的同时检查缓冲区状态,仅靠分区锁无法提供充分保护。他提到计划最终将缓冲区头部自旋锁的定义缩小到仅处理缓冲区身份变更。
https://www.postgresql.org/message-id/5bf667f3-5270-4b19-a08f-0facbecdff68@postgrespro.ru
🌐 社交媒体动态
🧩 优秀的存储系统能掩盖许多数据库问题

CYBERTEC 和 Lightbits Labs 发布了一份白皮书,专门解决 PostgreSQL 性能和迁移难题。该文档涵盖零停机迁移、NVMe-over-TCP 存储性能优化,以及降低 Oracle 许可成本的策略。这份白皮书主要面向处理 PostgreSQL 基础设施问题的数据库管理员,提供了改进数据库运维的完整框架,并可能帮助用户用 Postgr…
🧩 [演示]GenieCode:您的自主AI数据工作伙伴
Genie Code是一个专为数据工作设计的自主AI伙伴。该系统能够基于单一指令执行全面的数据任务,包括数据集探索、模型训练与评估、构建Lakeflow Spark声明式管道,以及创建AI/BI仪表板。在整个过程中,它会保持企业上下文,确保各项数据操作的相关性和一致性。
🧩 2026年企业科技30强榜单发布,Databricks位列GigaStage第二名!

2026年企业科技30强榜单正式发布,Databricks在Giga Stage类别中排名第二。这一年度榜单由90多位顶级风投机构和企业发展负责人评选产生,旨在表彰在企业技术领域发挥重要作用、推动未来工作方式变革的顶尖私人公司。此次荣誉由Wing Venture Capital和Eric Newcomer主导评选。
https://www.linkedin.com/posts/databricks_et30-activity-7444813352574545920-EzUS
🔥 HOW 2026 报名进行中
一场真正以技术为核心的 PostgreSQL 大会
HOW 2026 PostgreSQL & IvorySQL 技术峰会火热报名中
📍 2026 年 4 月 27 日 - 28 日|济南


浙公网安备 33010602011771号