PostgresQl почему второй запрос быстрее первого?

Question

[NubasLol]

Делаю полнотекстовый поиск на постгрес, но он почему-то работает очень медленно, но особенно первый запрос . Например слово президент встречется в 7 тысячах строк из 120к . Первый запрос занимает около 6 секунд, а уже второй такой же занимает 400мс . У меня tsvector хранится в одтельной колонке и по ней созад индекс gin

Answer 1

[good_beginer]

Для увеличения скоростити запростов надо бы проинтексировать таблицы, будет ощутимая разница а что касается разницы во времени по мойму это просто кэширование, тоесть он при повторном запросе он просто выводит последний результат и также смотрит есть ил разница между текушим состоянием таблицы и то что в памяти

Comments

[good_beginer]

Чтобы удостоверится, сделай запрос, повтори а потом добавь 1 запись и опять повтори, все эти запросы по времени будут сильно отличатся

[NubasLol]

Всю таблицу проиндексировать?Просто у меня и так есть индекс по колонке

[Melkij]

good_beginer, нет в postgresql query cache, никогда не было и разработчики старательно отвергают идеи это реализовывать. Тем более query cache нет уже и даже в mysql, те тоже наелись этого счастья и удалили.

[NubasLol]

Melkij, хеппи, друг, в чем тогда дело?Поиск по 30секунд иногда занимает

[good_beginer]

Melkij, Может не правильно выразился но я об этом
https://dev.mysql.com/doc/refman/5.6/en/innodb-dou...

[good_beginer]

и у postgresql такая штука есть

[Melkij]

good_beginer, а вы mysql от postgresql (см теги) вообще не отличаете? Это зря.
Ну и doublewrite буфер - это про операции записи и crash recovery.

[Melkij]

good_beginer,

и у postgresql такая штука есть

ммм. Нет. Такого нет.
Есть WAL - это write ahead log. Это не doublewrite буфер. Это именно транзакционный лог. И у mysql есть транзакционный лог, только по другому принципу организованный.
Postgresql изменения данных пишет сначала в WAL и потом только в shared_buffers, не на диск. Затем фоновые процессы bgwriter и checkpointer (а если не справляются - то и сами backend'ы) сбрасывают изменённые страницы данных на диск сразу в то место, где те должны быть.

[good_beginer]

Melkij, Отличаю просто у mysql понятнее по этому поводу... а что насчёт postgresql скорее всего моя документация устаревшая))

Answer 2

[Melkij]

Смотрите explain (analyze, buffers), сильно желательно с включенным track_io_timing. Почти наверняка первый запрос вы читаете с диска, второй - уже из shared_buffers. Либо с page cache операционной системы.

Comments

[NubasLol]

Ну а как можно оптимизировать поиск, что бы всегда быстро работало?

[Melkij]

Ставить нормальные диски и адекватное для размера своей базы количество RAM и shared_buffers

Answer 3

[lega]

Что-бы было быстро:
1) берите необходимое кол-во данных, например 50-100 первых, вместо выкачивания всего.
2) Используйте специализированные инструменты (sphinxsearch/elasticsearch).

Answer 4

[Андрей]

потому что постгря кеширует данные, которые прочитала для выполнения запроса.