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 时代不再是假设。