Как уменьшить planning time в postgresql?

Question

[Сергей Волков]

Сервер сайта использует laravel и postgresql.
Для поиска используется полнотекстовый поиск (tsearch2) использующий русские словари.
Проблема в том, что поиск русского текста длится дольше чем текста из латинских символов.
Покажу на примере
Запрос с русским текстом

explain analyze
SELECT *
FROM lots 
WHERE search_index @@@ to_tsquery('рус:*') 
LIMIT 100 
OFFSET 100

Получаем

Planning time: 494.529 ms
Execution time: 3.871 ms

Запрос с английским текстом

explain analyze
SELECT *
FROM lots 
WHERE search_index @@@ to_tsquery('eng:*') 
LIMIT 100 
OFFSET 100

Получаем

Planning time: 2.229 ms
Execution time: 0.700 ms

По результатам видно, что в первом случае Planning Time почти половина секунды, когда во втором случае 2.229 мс.
Вот этот Planning Time хотелось бы уменьшить.

Важно. Заметил одну особенность. Приведенные выше запросы я выполняю через pgAdmin3. Открываю окошко для ввода sql запроса, ввожу запрос, выполняю, Planning Time = 0.5 сек. Но если, не закрывая окна, выполнить этот запрос второй раз, то Planning Time = 0.3 мс. Но на сервере получается что каждый запрос делается как первый раз, то есть с большим Planning Time.

Answer 1

[He11ion]

Я думаю потому что план попадает в кэш.
Как вариант - использовать подготовленные запросы или не разрывать соединение (pgbouncer в помощь).

Comments

[Сергей Волков]

Спасибо.
Подготовленные запросы скорее всего не подходят, хотя надо получше их изучить. Не нашел пока хорошего описания с примерами и предназначением этого функционала.
А вот pgbounces хорошая идея. И в будущем понадобится даже без таких запросов. Сегодня буду пробовать. Отпишусь.

[Сергей Волков]

PGBouncer помог. Спасибо большое.

Answer 2

[Игорь Русинов]

Неплохо было бы взглянуть на полный вывод EXPLAIN ANALYZE, но предполагаю, что причина в том, что первый запрос вытаскивает все данные с диска, а при запуске второго запроса postgresql уже закешировал часть данных. Ну и как сказал He11ion, план запроса тоже кешируется на сессию. Соответственно сравнение не корректное получилось. Если первым запустить поиск с английским словам, а потом по русским, я думаю результат эксперимента будет обратным.

Comments

[Сергей Волков]

Нет. Я делал 2 одинаковых запроса подряд (с русскими буквами), второй был такой же быстрый как и с английскими буквами. Замеры делал и в pgAdmin3 и прямо в коде выполнял 2 таких запроса с замером времени выполнения. Результаты одинаковые.

Вот полный вывод
"Limit (cost=532.93..743.88 rows=58 width=1281) (actual time=3.897..5.156 rows=100 loops=1)"
" -> Bitmap Heap Scan on lots (cost=169.22..743.88 rows=158 width=1281) (actual time=2.531..4.213 rows=200 loops=1)"
" Recheck Cond: (search_index @@@ to_tsquery('рус:*'::text))"
" Heap Blocks: exact=176"
" -> Bitmap Index Scan on lots_search (cost=0.00..169.18 rows=158 width=0) (actual time=1.333..1.333 rows=539 loops=1)"
" Index Cond: (search_index @@@ to_tsquery('рус:*'::text))"
"Planning time: 609.022 ms"
"Execution time: 5.515 ms"

А вот сразу выполненный второй (в том же окне pgAdmin'а)
"Limit (cost=532.93..743.88 rows=58 width=1281) (actual time=2.806..4.589 rows=100 loops=1)"
" -> Bitmap Heap Scan on lots (cost=169.22..743.88 rows=158 width=1281) (actual time=1.368..3.290 rows=200 loops=1)"
" Recheck Cond: (search_index @@@ to_tsquery('рус:*'::text))"
" Heap Blocks: exact=176"
" -> Bitmap Index Scan on lots_search (cost=0.00..169.18 rows=158 width=0) (actual time=1.078..1.078 rows=539 loops=1)"
" Index Cond: (search_index @@@ to_tsquery('рус:*'::text))"
"Planning time: 0.570 ms"
"Execution time: 5.117 ms"

[Сергей Волков]

И еще английский и русский запросы я запускал в разных окнах. И в одном окне, меняя порядок. Всегда английский запрос побеждает по времени.
Если в одном окне сначала английский - то он как всегда быстрый. А если следом запустить русский запрос, то он долгий. А вот второй русский - быстрый.