概要
この記事 で検索速度を計測していたのですが、pg_bigm が本気を出せていない感じはしてました。
そうしたら「lossy が出てrecheckが発動しているから work_mem を増やすといいかも！」と教えてもらったので試します。
テーブルとかデータとか
この記事 の通りなので参照してください。
早速実験
test_articles=# show work_mem;
work_mem
----------
4MB
(1 row)
test_articles=# explain analyze select * from wikipedia where text like '%象%';
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on wikipedia (cost=190.38..39822.23 rows=14788 width=491) (actual time=30.897..16784.208 rows=192783 loops=1)
Recheck Cond: (text ~~ '%象%'::text)
Rows Removed by Index Recheck: 470347
Heap Blocks: exact=39863 lossy=33170
-> Bitmap Index Scan on wikipedia_index (cost=0.00..186.68 rows=14788 width=0) (actual time=26.679..26.680 rows=133358 loops=1)
Index Cond: (text ~~ '%象%'::text)
Planning Time: 0.949 ms
Execution Time: 16788.259 ms
(8 rows)
試しに16MBに増やす。
test_articles=# set work_mem = '16MB';
SET
test_articles=# explain analyze select * from wikipedia where text like '%象%';
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on wikipedia (cost=190.38..39822.23 rows=14788 width=491) (actual time=41.194..167.356 rows=192783 loops=1)
Recheck Cond: (text ~~ '%象%'::text)
Heap Blocks: exact=73033
-> Bitmap Index Scan on wikipedia_index (cost=0.00..186.68 rows=14788 width=0) (actual time=34.356..34.357 rows=192783 loops=1)
Index Cond: (text ~~ '%象%'::text)
Planning Time: 0.271 ms
Execution Time: 170.693 ms
(7 rows)
すごくはやくなった！
まとめ
Heap Blocks: exact=39863 lossy=33170 とか出て、思ったより遅いときは、work_mem を増やすとはやくなる。
ただし、闇雲に増やすとサーバーのメモリ使用量が増えて大変なことになることもあるので、要注意。
（Swapを使いまくって逆に遅くなるとか。）