为什么PostgreSQL 11优化器拒绝使用带有包含列的索引的最佳计划？

Question

PostgreSQL 11不够聪明，无法使用包含列的索引吗？

CREATE INDEX organization_locations__org_id_is_headquarters__inc_location_id_ix
ON organization_locations(org_id, is_headquarters) INCLUDE (location_id);

ANALYZE organization_locations;
ANALYZE organizations;

EXPLAIN VERBOSE
SELECT location_id
FROM organization_locations ol
WHERE org_id = (SELECT id FROM organizations WHERE code = 'akron')
AND is_headquarters = 1;

QUERY PLAN
Seq Scan on organization_locations ol  (cost=8.44..14.61 rows=1 width=4)
  Output: ol.location_id
  Filter: ((ol.org_id = $0) AND (ol.is_headquarters = 1))
  InitPlan 1 (returns $0)
    ->  Index Scan using organizations__code_ux on organizations  (cost=0.42..8.44 rows=1 width=4)
          Output: organizations.id
          Index Cond: ((organizations.code)::text = 'akron'::text)

[organization_locations当前只有211行，平均行长度为91个字节。

我只能加载一个数据页。但是，获取索引页的I / O是相同的，并且目标数据就在那里（无需从索引对数据页进行额外查找）。 PG对这个计划有何想法？

这只是为我创建了一个待办事项，可以四舍五入并检查以确保一旦桌子出现后就开始生成正确的计划。

Answer 1

读取一个索引页并不比读取表页便宜，因此对于小型表，您不能指望仅索引扫描会有所帮助。

此外，你呢

VACUUM organization_locations;

否则，可见性图将不会显示该表块是全可见的，因此无论如何您都无法获得仅索引的扫描。