PostgreSQL GIN 索引比 pg_trgm 的 GIST 慢嗎？

Question

盡管所有文檔都說了些什么，但我發現 GIN 索引比 pg_trgm 相關搜索的 GIST 索引慢得多。 這是一個包含 2500 萬行的表格，其中包含一個相對較短的文本字段（平均長度為 21 個字符）。 大多數文本行都是“123 Main st, City”形式的地址。

GIST 索引大約需要 4 秒，搜索如下

select suggestion from search_suggestions where suggestion % 'seattle';

但是當使用EXPLAIN ANALYZE運行時，GIN 需要 90 秒和以下結果：

Bitmap Heap Scan on search_suggestions  (cost=330.09..73514.15 rows=25043 width=22) (actual time=671.606..86318.553 rows=40482 loops=1)
  Recheck Cond: ((suggestion)::text % 'seattle'::text)
  Rows Removed by Index Recheck: 23214341
  Heap Blocks: exact=7625 lossy=223807
  ->  Bitmap Index Scan on tri_suggestions_idx  (cost=0.00..323.83 rows=25043 width=0) (actual time=669.841..669.841 rows=1358175 loops=1)
        Index Cond: ((suggestion)::text % 'seattle'::text)
Planning time: 1.420 ms
Execution time: 86327.246 ms

請注意，索引選擇了超過一百萬行，即使實際上只有 40k 行匹配。 任何想法為什么這表現如此糟糕？ 這是在 PostgreSQL 9.4 上。

Answer 1

一些問題很突出：

首先，考慮升級到當前版本的 Postgres 。 在撰寫本文時，它是第 9.6 頁或第 10 頁（目前是測試版）。 自 Pg 9.4 以來，對 GIN 索引、附加模塊 pg_trgm 和大數據進行了多項改進。

接下來，您需要更多RAM ，尤其是更高的work_mem設置。 我可以從EXPLAIN輸出中的這一行看出：

Heap Blocks: exact=7625 lossy=223807

位圖堆掃描（使用您的特定數字）的詳細信息中的“有損”表明work_mem嚴重短缺。 Postgres 只收集位圖索引掃描中的塊地址，而不是行指針，因為使用較低的work_mem設置（不能在 RAM 中保存確切地址）預計會更快。 在下面的位圖堆掃描中，必須以這種方式過濾更多不合格的行。 這個相關的答案有詳細信息：

• 帶有位圖索引掃描的查詢計划中的“重新檢查條件：”行

但是不要在不考慮整個情況的情況下將work_mem設置work_mem太高：

• 使用 ORDER BY 日期和文本優化簡單查詢

可能還有其他問題，例如索引或表膨脹或更多配置瓶頸。 但是，如果你只是解決這兩個項目，查詢要快很多了。

另外，您真的需要檢索示例中的所有 40k 行嗎？ 你可能要一個小添加LIMIT的查詢，使之成為“近鄰”搜索-在這種情況下，其主旨在於指數畢竟是更好的選擇，因為這應該是與要旨的索引快。 例子：

• 相似度函數的最佳索引