我原本不认为索引组织表扫描所有可见元组时一定更快。从逻辑上讲,它必须通过相同数量的数据,无论是将数据组织成B树叶节点还是现有堆格式。目前,PostgreSQL索引仅存储[key,ctid]对(基本上)。 (ctid基本上是“rowid” - 堆页号和元组行指针索引)因此,您不能仅通过遍历索引来计算表中的行数,因为您需要检查每个元组的[xmin,xmax]--而这仅保留在堆中的数据中。您也可以将[xmin,xmax]放入索引中-这种建议不时出现。但是,这会使索引膨胀,并且为了有用,所有更新/删除都必须确保它们保持最新状态:这会导致问题,尤其是因为进行更新所涉及的工作现在已经扩展了一些乘以表上索引的数量。在诸如tsvector之类的重型索引或基于昂贵用户表达式的索引的情况下,这可能需要一段时间,在某些恶劣情况下根本不起作用,因为行现在似乎在索引中处于活动状态,但在堆中已死亡。并且这个练习的整个重点是让数据库尽可能仅依赖于索引中的活动信息。即使您正在更新未索引的列,也会产生这些成本-团队在8.3中做出了一些努力以加快这个过程(仅堆元组)。我想一个可能性是将索引标记为可选择具有[xmin,xmax]-例如仅以此方式标记pkey索引。然后必须进行计划者更改以弄清楚何时这是优势-这似乎需要相当多的工作。如果索引组织表像我认为Oracle中的工作方式一样(以及SQL Server,在其中具有聚集索引的任何表格基本上都是索引组织的),则在主键索引中存储[key,tuple](并且可能在其他所有索引中存储[key,pkey])-没有ctid,没有堆。因此,“元组”将包含[xmin,xmax,cminmax,natts,....]等,您可以通过扫描索引来满足“从表中选择计数(*)”。但这基本上就像扫描堆上的元组一样-它们不会因为现在在“索引”中而变得神奇地占用更少的空间。据我所知,索引组织表的主要原因是小型表格具有单个主键索引,将占用1页而不是3页,并且按主键进行的索引扫描可能会稍微快一些。我确实记得为IOT提供的与Oracle相关的建议是,它们旨在用于静态维度表,而不是通用用途,部分原因是对维护辅助索引施加的成本(我认为Oracle不会在IOT辅助索引中存储[key,pkey],而是某种替代rowid)。