postgresql - 返回 0 行时 GIN 索引不用于小表

Question

在 Postgres 9.4 数据库中，我在名为“persons”的表上创建了一个 GIN 三元组索引，该表包含 1514 行，如下所示:

CREATE INDEX persons_index_name_1 ON persons
USING gin (lower(name) gin_trgm_ops);

以及查找类似名称的查询，如下所示:

select name, last_name from persons where lower(name) % 'thename'

因此，我首先使用一个我事先知道的名称发出了一个查询，该名称将具有相似的匹配项，因此 explain analyze 显示我创建的索引用于此查询:

select name, last_name from persons where lower(name) % 'george'

结果是预期的:

  ->  Bitmap Heap Scan on persons  (cost=52.01..58.72 rows=2 width=26) (actual time=0.054..0.065 rows=1 loops=1)
        Recheck Cond: (lower((name)::text) % 'george'::text)
        Rows Removed by Index Recheck: 2
        Heap Blocks: exact=1
        ->  Bitmap Index Scan on persons_index_name_1  (cost=0.00..52.01 rows=2 width=0) (actual time=0.032..0.032 rows=3 loops=1)
              Index Cond: (lower((name)::text) % 'george'::text)
...
Execution time: 1.382 ms"

所以，出于好奇，我想看看当 thename 参数包含一个表中根本不存在的名称时是否使用了索引:

select name, last_name from persons where lower(name) % 'noname'

但我看到在这种情况下根本没有使用索引并且执行时间要长得多:

  ->  Seq Scan on persons  (cost=0.00..63.72 rows=2 width=26) (actual time=6.494..6.494 rows=0 loops=1)
        Filter: (lower((name)::text) % 'noname'::text)
        Rows Removed by Filter: 1514
...
Execution time: 7.387 ms

作为测试，我对 GIST 索引进行了相同的尝试，在这两种情况下，都使用了索引，执行时间与上面的第一种情况一样。

我继续重新创建表格，但这次插入了 10014 行；我看到在上面的两种情况下，都使用了 GIN 索引，并且执行时间对于这些情况来说是最好的。

当上面的查询在行数不多(在我的例子中是 1514)的表中没有返回任何结果时，为什么不使用 GIN 索引？

Answer 1

三字母索引不区分大小写，测试:

select 'case' <-> 'CASE' AS ci1
     , 'case' %   'CASE' AS ci2
     , 'CASE' <-> 'CASE' AS c1
     , 'CASE' %   'CASE' AS c2;

所以你不妨:

CREATE INDEX persons_index_name_1 ON persons USING gin (name gin_trgm_ops);

和:

select name, last_name from persons where name % 'thename';

至于您的实际问题，对于小表，索引查找可能无济于事。这正是您添加的测试所证明的。并且建立无匹配可能比找到一些匹配更昂贵。

除此之外，您的成本设置和/或表统计信息可能未达到各自的最佳状态，无法让 Postgres 选择最合适的查询计划。

预期成本数字转化为顺序扫描比位图索引扫描多的实际成本。与顺序扫描相比，您可能高估了索引扫描的成本。 random_page_cost (并且 cpu_index_tuple_cost) 可能设置得太高而 effective_cache_size 太低。

• Keep PostgreSQL from sometimes choosing a bad query plan