Question

在Postgres 9.4数据库中，我在名为“人物”的桌子上创建了一个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索引，并且执行时间最适合这些情况。

为什么当上面的查询在没有多行的表中返回结果时没有使用GIN索引（在我的情况下为1514）？

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

至于你的实际问题，对于小型表，索引查找可能不会支付。这正是您添加的测试所展示的内容。确定 nothing 匹配可能比找到一些匹配更加昂贵。

除此之外，您的费用设置和/或表格统计信息可能不是各自的最佳值，以便让Postgres选择最合适的查询计划。

预期成本数转换为很多顺序扫描的实际成本高于位图索引扫描的实际成本。与顺序扫描相比，您可能会过高估计索引扫描的成本。 random_page_cost {和cpu_index_tuple_cost)可能设置得太高且effective_cache_size太低。

Keep PostgreSQL from sometimes choosing a bad query plan

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

1 个答案: