Question

这个问题是这个主题的后续问题：

question about performance of ILIKE search with 2 wildcards

我请求帮助改进在几个字段的ILIKE语句中包含的搜索方法的性能。我提出了两个我已经实现的解决方案，首先将相关字段的信息连接到搜索以避免有5个ILIKE语句，另一个是避免常规的b树索引，因为它们在查找时没用使用2个通配符的单词。我决定使用trigram索引，因为我读到了它们在这些情况下是如何有用的。

问题是，我的性能没有任何相关的改进，所以我想知道这些索引是否正在使用。问题是如何知道这些新的三元组索引是否有效？

我已经尝试过对我的查询进行解释分析，但没有关于索引的说法：

Hash Join  (cost=971.56..2042.73 rows=3137 width=197) (actual         time=22.189..151.067 rows=2781 loops=1)
Hash Cond: ((part_variants.sap_cod)::text = (part_masters.sap_cod)::text)
Join Filter: ((part_masters.combinada_maestro ~~* '%rodamiento%'::text)    OR (part_variants.combinada_info ~~* '%rodamiento%'::text))
Rows Removed by Join Filter: 48682
->  Seq Scan on part_variants  (cost=0.00..826.52 rows=51506 width=64)   (actual time=0.005..7.943 rows=51463 loops=1)
->  Hash  (cost=853.88..853.88 rows=33625 width=133) (actual  time=21.496..21.496 rows=33653 loops=1)
      Buckets: 65536  Batches: 1  Memory Usage: 6310kB
     ->  Seq Scan on part_masters  (cost=0.00..853.88 rows=33625  width=133) (actual time=0.004..9.115 rows=33653 loops=1)
Planning time: 2.361 ms
Execution time: 151.276 ms
(10 rows)

查询是这样的：

SELECT * FROM part_masters INNER JOIN part_variants ON 
part_variants.sap_cod = part_masters.sap_cod WHERE (combinada_maestro  
ILIKE  '%rodamiento%' OR combinada_info ILIKE '%rodamiento%');

顺便说一下，explain分析工具显示的执行时间比实际的ActiveRecord时间慢（大约一秒）

Answer 1

https://www.postgresql.org/docs/current/static/pgtrgm.html

从PostgreSQL 9.1开始，这些索引类型也支持索引搜索LIKE和ILIKE

因此，您应该在执行计划中看到新创建的索引。虽然您的计划显示您使用NO INDICES（Seq. Scan）。

你能做什么：

analyze part_masters和analyze part_variants（特别是如果你没有这样做的话）
set enable_seqscan to off并再次检查执行计划（以确保您创建的索引加快查询速度）
如果索引会加快查询速度，但查询计划程序尽管有新的统计信息仍然不使用它们，请检查effective_cache_size，enable_indexscan，random_page_cost等等以查找原因

我如何知道是否实际使用了三元组索引？

1 个答案: