当返回 0 行时，GIN 索引不用于小 table

Question

在 Postgres 9.4 数据库中，我在名为 'persons' 的 table 上创建了一个 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 参数包含一个在 table 中根本不存在的名称时是否使用了索引：

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 索引进行了同样的尝试，在这两种情况下，都使用了索引，执行时间与上面的第一种情况一样。

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

当上面的查询 returns 没有结果 table 没有那么多行（在我的例子中是 1514）时，为什么不使用 GIN 索引？

Answer 1

Trigram 索引 不区分大小写，测试：

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';

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

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

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

Keep PostgreSQL from sometimes choosing a bad query plan

当返回 0 行时，GIN 索引不用于小 table

GIN index not used for small table when 0 rows returned

postgresql

indexing

pattern-matching

postgresql-performance