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

Question

PostgreSQL 11 isn't smart enough to use indexes with included columns?

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)

There are only 211 rows currently in organization_locations, average row length 91 bytes.

I get only loading one data page. But the I/O is the same to grab the index page and the target data is right there (no extra lookup into the data page from the index). What is PG thinking with this plan?

This just creates a TODO for me to round back and check to make sure the right plan starts getting generated once the table burgeons.

EDIT: Here is the explain with buffers:

Seq Scan on organization_locations ol  (cost=8.44..14.33 rows=1 width=4) (actual time=0.018..0.032 rows=1 loops=1)
  Filter: ((org_id = $0) AND (is_headquarters = 1))
  Rows Removed by Filter: 210
  Buffers: shared hit=7
  InitPlan 1 (returns $0)
    ->  Index Scan using organizations__code_ux on organizations  (cost=0.42..8.44 rows=1 width=4) (actual time=0.008..0.009 rows=1 loops=1)
          Index Cond: ((code)::text = 'akron'::text)
          Buffers: shared hit=4
Planning Time: 0.402 ms
Execution Time: 0.048 ms

Answer 1

Reading one index page is not cheaper than reading a table page, so with tiny tables you cannot expect a gain from an index-only scan.

Besides, did you

VACUUM organization_locations;

Without that, the visibility map won't show that the table block is all-visible, so you cannot get an index-only scan no matter what.

Answer 2

In addition to the other answers, this is probably a silly index to have in the first place. INCLUDE is good when you need a unique index but you also want to tack on a column which is not part of the unique constraint, or when the included column doesn't have btree operators and so can't be in the main body of the index. In other cases, you should just put the extra column in the index itself.

This just creates a TODO for me to round back and check to make sure the right plan starts getting generated once the table burgeons.

This is your workflow problem that you can't expect PostgreSQL to solve for you. Do you really think PostgreSQL should create actual plans based on imaginary scenarios?