我已经在我的网站上使用GIN tsvector实现了FTS引擎,并且效果很好,但是有几次似乎花了很长时间,没有具体原因。我在下面复制EXPLAIN ANALYE命令的输出:
map
我认为在某个时候更改work_mem会有所帮助。我将其设置为86MB,并且仍然相同。
奇怪的是,如果我此后立即重新运行同一命令,它将更快。见下文:
sitedb=# EXPLAIN ANALYZE SELECT id, title FROM post_1 WHERE search_vector @@ to_tsquery('quantum');
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on post_1 (cost=315.68..105654.80 rows=32443 width=106) (actual time=76.963..17281.184 rows=31925 loops=1)
Recheck Cond: (search_vector @@ to_tsquery('quantum'::text))
Heap Blocks: exact=29259
-> Bitmap Index Scan on index1_idx (cost=0.00..307.57 rows=32443 width=0) (actual time=60.208..60.209 rows=31925 loops=1)
Index Cond: (search_vector @@ to_tsquery('quantum'::text))
Planning Time: 47.648 ms
Execution Time: 17308.511 ms
(7 rows)
任何人都会有个主意吗?
非常感谢您。
答案 0 :(得分:1)
这可能是冷缓存。例如,它必须读取29,259页,而其中很少已经存在于内存中。第二次运行它时,它们在内存中,因此速度更快。您可以在打开track_io_timing后执行EXPLAIN (ANALYZE, BUFFERS)
来帮助确认这一点。
您可以增加effective_io_concurrency,以使PostgreSQL一次具有多个未解决的IO请求。效果如何取决于您的IO硬件。例如,它应在带区RAID或JBOD上更有效。
如果由于最近重新启动而导致缓存很冷,那么不要经常重启,或者在执行操作时使用pg_prewarm来预热缓存。如果由于经常使用的数据太大而无法保留在内存中而无法保留在高速缓存中,则获取更多的RAM或获取更快的磁盘(例如SSD,如果已经是SSD,则获取更好的磁盘)。 / p>