PostgreSQL索引扫描时为什么index only scan不返回ctid（post visit）新鲜出炉

这篇文章讨论了PostgreSQL中索引扫描时使用`index only scan`的问题，尤其是当查询涉及`ctid`（常量行ID）时的情况。以下是文章的核心内容总结： 1. **什么是`index only scan`？** - 在PostgreSQL中，`index only scan`是一种高效的查询优化方式，仅通过索引获取符合条件的数据，而无需回表（`table access by index rowid`）。 - 类似于其他数据库如Oracle，`index only scan`在某些情况下可以显著提高查询性能。 2. **`ctid`与索引扫描的关系** - `ctid`是PostgreSQL索引中的一个特殊字段，通常用于唯一性检查。在传统PostgreSQL中，使用`ctid`时，优化器无法使用`index only scan`，而是会使用普通索引扫描。 - 这是因为PostgreSQL的优化机制（`check_index_only`函数）无法识别`ctid`字段的特殊性，认为这些数据可能需要通过回表获取。 3. **`index only scan`的判断机制** - PostgreSQL通过索引的`index_canreturn_attrs`位图来判断是否可以使用`index only scan`。这个位图记录了索引支持返回的字段。 - 查询所需的字段（`attrs_used`）是否是`index_canreturn_attrs`的子集，决定了是否使用`index only scan`。 - 然而，`index_canreturn_attrs`不包含`ctid`字段的信息，因此无法识别`ctid`的特殊性。 4. **`HOT`与索引可见性** - 优化器在解析阶段通过`vm_files`判断索引的可见性，以避免错误的使用`index only scan`。 - 但即使表中没有不可见的行，`index only scan`仍然无法处理涉及`ctid`的查询，因为`ctid`的特殊性在索引中被隐藏。 5. **结果** - 使用`ctid`时，PostgreSQL只能使用普通索引扫描（`index scan`），而无法使用`index only scan`。 - 这是由于PostgreSQL的索引优化机制无法正确识别`ctid`的特殊性，导致无法优化查询方式。 这篇文章揭示了PostgreSQL在索引优化方面的限制，特别是在处理涉及`ctid`的查询时。理解这些机制有助于开发者更好地使用PostgreSQL的性能优化功能。