PostgreSQL中的所有索引都是二级索引，也就是说，每个索引都与表的主数据区分开存储（在PostgreSQL术语中，这个主数据区称为表的堆）。这意味着，在普通索引扫描中，每次取回一行都需要同时从索引和堆中取数据。此外，尽管满足某个可索引WHERE条件的索引项通常在索引中彼此接近，但它们引用的表行却可能分布在堆中的任何位置。因此，索引扫描的堆访问部分会涉及大量对堆的随机访问，这可能很慢，尤其是在传统旋转介质上。（正如Section 11.5中所述，位图扫描试图通过按排序顺序进行堆访问来缓解这项代价，但那也只能缓解到一定程度。）
为了解决这一性能问题，PostgreSQL支持仅索引扫描，仅通过索引就能完成查询，无需访问堆。其基本思路是直接从各个索引项返回值，而不访问相关联的堆项。使用这种方法有两个基本限制：
索引类型必须支持仅索引扫描。B-树索引总是支持。GiST 和 SP-GiST 索引对某些操作符类支持仅索引扫描，但对另一些则不支持。其他索引类型则完全不支持。底层要求是，索引必须实际存储原始数据值，或者至少能够重建出每个索引项对应的原始数据值。反例是 GIN 索引，它不能支持仅索引扫描，因为每个索引项通常只保存原始数据值的一部分。
查询只能引用存储在索引中的列。例如，假设某个表的x和y列上有一个索引，且该表还有一列z，那么以下查询可以使用仅索引扫描：
SELECT x, y FROM tab WHERE x = 'key'; SELECT x FROM tab WHERE x = 'key' AND y < 42;
但以下查询不能：
SELECT x, z FROM tab WHERE x = 'key'; SELECT x FROM tab WHERE x = 'key' AND z < 42;
（表达式索引和部分索引会使这条规则更复杂，下文将作讨论。）
如果这两个基本要求满足，那么查询所需的所有数据值都能从索引中取得，因此从物理上说仅索引扫描是可行的。不过，在PostgreSQL中，任何表扫描还有一个额外要求：它必须验证每个取回的行对该查询的 MVCC 快照是否“可见”，如Chapter 13所述。可见性信息并不保存在索引项中，而只保存在堆项中；因此乍看之下，似乎每次取回行无论如何都要访问堆。这在表行最近被修改过时的确如此。然而，对于很少变化的数据，这个问题有办法绕开。PostgreSQL会跟踪表堆中每个页面是否其中所有行都已经足够老，以至于对当前和未来所有事务都可见。这个信息保存在该表的可见性映射中的一个位里。仅索引扫描在找到候选索引项后，会检查对应堆页面的可见性映射位。如果该位已设置，那么这行就已知可见，数据可以直接返回而无需进一步工作。如果没有设置，就必须访问堆项来判断该行是否可见，这样相对标准索引扫描就没有性能优势。即使在成功的情况下，这种做法也是用访问可见性映射来替代访问堆；但由于可见性映射比它描述的堆小四个数量级，访问它所需的物理 I/O 要少得多。在大多数场景下，可见性映射始终都会缓存于内存中。
简而言之，尽管满足那两个基本要求时就有可能使用仅索引扫描，但只有当表中相当一部分堆页的“全部可见”（all-visible）映射位已被设置时，它才会带来收益。不过，很多表都会有相当大一部分行长期不变，因此这种扫描方式在实践中非常有用。
为了有效利用仅索引扫描，可以创建这样的索引：只有前导列用于匹配WHERE子句，而后面的列保存查询需要返回的“负载”数据。例如，如果经常执行如下查询：
SELECT y FROM tab WHERE x = 'key';
加快此类查询的传统做法，是仅在以下列上创建索引：x。但是，在(x, y)上创建索引，就可能通过仅索引扫描实现该查询。如前所述，这种索引会比仅在x上创建的索引更大，因而代价也更高，所以只有在已知表基本静态的情况下，这种做法才有吸引力。注意，索引必须声明在(x, y)上，而不是(y, x)上，因为对于大多数索引类型（尤其是 B-树），不约束索引前导列的搜索效率不高。
原则上，仅索引扫描也可以和表达式索引一起使用。例如，给定一个f(x)上的索引，其中x是表的一列，那么按理说应该可以把
SELECT f(x) FROM tab WHERE f(x) < 1;
执行成一次仅索引扫描；如果f()是一个计算代价很高的函数，这会非常有吸引力。不过，PostgreSQL的规划器目前在这种情况上还不够聪明。它只会在查询所需的所有列都能从索引取得时，才认为查询可能通过仅索引扫描执行。在这个例子里，除了在f(x)这个上下文中，x本身并不需要，但规划器意识不到这一点，因此得出无法做仅索引扫描的结论。如果仅索引扫描看起来足够值得，可以通过在(f(x), x)上声明索引来绕过这一点。第二列实际上并不预期会被使用，加入它只是为了让规划器认为仅索引扫描是可行的。 还有一个额外注意事项：如果目标是避免重新计算f(x)，那么规划器不一定会把那些不在可索引WHERE子句中的f(x)用法与索引列匹配起来。对于上面展示的简单查询，它通常能做对，但对于涉及连接的查询则不能。未来版本的PostgreSQL可能会修复这些不足。
部分索引与仅索引扫描之间也有有趣的相互作用。考虑Example 11.3中展示的这个部分索引：
CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
WHERE success;
原则上，我们可以在这个索引上做仅索引扫描，以满足如下查询：
SELECT target FROM tests WHERE subject = 'some-subject' AND success;
但这里有个问题：WHERE子句引用了success，而它并不能作为索引的结果列取得。尽管如此，仍然可能做仅索引扫描，因为执行计划在运行时不需要重新检查WHERE子句的这一部分：索引中找到的所有项都必然满足success = true，因此计划里无需显式检查它。PostgreSQL 9.6 及更高版本能够识别这种情况，并允许生成仅索引扫描；更早的版本则不能。