DeepSeek总结的PostgreSQL 表访问方法

来源https://thebuild.com/blog/2026/05/20/table-access-methods-wake-up/PostgreSQL 表访问方法醒醒吧作者:Christophe Pettus日期:2026-05-20表访问方法 API 自 PostgreSQL 12 版本开始就存在了。在它存在的大部分时间里它一直是一个安静的底层设施几乎没有扩展活动与之相关——一种在文档中占一个段落、在会议上有一个热情的演讲然后就是五年沉默的 API。这种情况正在改变。在过去的一个月里两个与 TAM 相关的扩展发布了重要版本。storage_engine1.0.7 为 PG 16-18 增加了面向列的压缩和行压缩访问方法。pg_sorted_heap0.13.0 提供了一个物理排序的堆带有区域映射修剪和一个与规划器集成的向量搜索钩子。这两者都不会在明天取代默认的堆。但它们都在做一些足够有趣的事情值得一看。最初的承诺以及它为何停滞不前TAM API 最初的承诺是存储布局可以按表进行交换而无需触及规划器和执行器的其余部分。实际情况则不那么干净。TAM 接口在几个地方假设了一个元组形状的记录这对于行存储变体来说没问题但对于列式存储来说则不舒服。默认情况下成本估计不知道你自定义存储的访问模式因此规划器会愉快地为那些本应进行区域映射修剪的布局生成顺序扫描计划。大多数早期的 TAM 扩展要么接受规划器的成本导致慢速计划要么提供扩展特定的规划器钩子这带来了维护负担并且每个主要版本都会出现问题。这两种结果都没有激发出后续工作的浪潮。现在不同的是在扩展中提供规划器钩子的成本已经降低并且对其的需求已经增加。pg_sorted_heap实际在做什么pg_sorted_heap有趣之处在于它将用于范围和向量相似性查询的规划器钩子直接集成到访问方法中。堆按用户指定的键进行物理排序。该键上的区域映射与堆一起维护。规划器被告知这两者。对排序键的范围查询在扫描时修剪整个区域无需索引。向量域中的最近邻查询使用相同的机制作为粗略的第一遍然后进行精炼。这是一个真实的架构模式——它出现在 DuckDB、ClickHouse、每个现代 Parquet 读取器以及早期的pg_lake扩展代码中——最终通过 TAM 进入标准 PostgreSQL。实现的稳健性是另一个问题。0.13.0 版本还很早期。但其设计是正确的设计。storage_engine在做什么storage_engine1.0.7 做了一些不同的事情新颖程度较低但更直接有用。colcompress访问方法将列打包到压缩的运行中并在读取时支付解包成本。rowcompress访问方法在常规行布局之上进行块级压缩。两者都是有限度的实验。都不会成为你的主要 OLTP 表。两者在堆和 TOAST 无法满足需求的特定场景中都很有用。如果你有宽列的、主要追加的表包含高基数的 varchar 列并且你一直在说服自己构建一个单独的分析副本在你这样做之前请先看看这个。接下来会发生什么未来一年值得关注的是为 PG19/PG20 提出的核心列式工作与 TAM 扩展生态系统是趋同还是分化。社区的方向广泛地朝向更强的可插拔性——更细粒度的 TAM 钩子、无需解析pgsql-hackers上每个补丁的规划器集成点以及一个自定义存储可以插入的真实成本估算方案。供应商的方向Snowflake、Databricks、Microsoft都在其 Postgres 形态产品的下面有专有存储层则广泛地背离这一点因为它们的差异化位于 TAM 线之下而可插拔性会削弱其护城河。无论哪一方赢得未来两年的架构心智份额都将决定 2028 年“Postgres”的含义。我有一个偏好。你可以猜到是什么。今天实际的答案是运行基准测试。两个扩展都有足够稳定的版本你可以这样做。TAM 时代不再是假设。