Question

我按以下顺序做了。添加了tsvector列

ALTER TABLE MYTABLE ADD COLUMN SEARCHABLE_TEXT TSVECTOR;

并填充现有列

UPDATE MYTABLE SET searchable_text = to_tsvector('english', MYCOLUMN);

此查询耗时约200毫秒

SELECT * FROM MYTABLE
WHERE searchable_text @@ to_tsquery('text');

现在创建了一个索引

CREATE INDEX MYTABLE_FTS_IDX ON MYTABLE USING GIN (SEARCHABLE_TEXT);

相同的选择查询大约需要10到15毫秒。这在我当地的Postgres框中有效。

所以我在我的生产盒上做了同样的事情，但是即使在创建MYTABLE_FTS_IDX索引之后，相同的选择查询仍然需要200-300ms。尽管我应用了相同的东西，为什么索引在某些实例上不起作用？

我能想到的另一件事是，我已经创建了一个english_stem字典并在生产框上删除，正如我在其他问题Postgres: two dictionaries with same name上所述

本地记录数为17k，prod数为40k。选择结果的数量约为400 - 500记录。

以下是解释分析的结果：

Bitmap Heap Scan on product  (cost=15.50..1255.12 rows=451 width=1447) (actual time=0.140..0.690 rows=452 loops=1)
  Recheck Cond: (searchable_text @@ to_tsquery('jean'::text))
  Heap Blocks: exact=363
  Buffers: shared hit=366
  ->  Bitmap Index Scan on product_search_idx  (cost=0.00..15.39 rows=451 width=0) (actual time=0.100..0.100 rows=452 loops=1)
        Index Cond: (searchable_text @@ to_tsquery('jean'::text))
        Buffers: shared hit=3
Planning time: 0.223 ms
Execution time: 0.781 ms

另一个奇怪的事情是，如果我使用'jean'进行搜索，它会显示结果，尽管它很慢。但如果我使用'牛仔裤'搜索，它会显示0记录！我觉得出了什么问题。

My Postgres版本是x86_64-unknown-linux-gnu上的PostgreSQL 9.4.5，由gcc（GCC）4.8.2 20140120（Red Hat 4.8.2-16）编译，64位

postgres：全文搜索索引不起作用

0 个答案: