![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
PostgreSQL: btree_gin + gin_fuzzy_search_limit = fail
Попробовал использовать довольно интересную фичу нового PostgreSQL - btee_gin. Это расширение, позволяющее засоввывать в поисковый индекс дополнительные поля, например дату, число или boolean (полный список поддерживаемых типов по ссылке).
Без этого расширения поиск по тексту с учетом дополнительных критериев всегда включает в себя полную выборку по текстовому запросу, которая затем так или иначе фильтруется по дополнительным критериям. С btree_gin можно стазу получить из индекса то что нужно, что (потенциально) быстрее.
Вторая полезная фича поиска - gin_fuzzy_search_limit, она появилась еще в 8.2 (или в 8.3). Этот режим позволяет ограничить выборку по индексу для запросов, которые выдают слишком много ответов, поскольку такие запросы исполняются долго и сильно грузят БД (особенно если потом хочется их всех отранжировать и отсортировать). Фактически это режим "выдачи глупых ответов на глупые запросы". Это значение не должно быть слишком маленьким, нужен еще некоторый запас на фильтрацию по нетекстовым критериям. gin_fuzzy_search_limit задает примерное максимальное число ответов, которое мы хотим получить.
Эксперимент по использованию gin_fuzzy_search_limit совместно с btee_gin по тексту и дате оказался не удачным. Для примера рассмотрим индекс по тексту и дате, и искать будем сообщения за последний год. Тестировалось два запроса - первый по слову "linux". При поиске без даты в индексе за год мы получали ~3000 ответов (gin_fuzzy_search_limit = 10000, остальное отфильтроввывавалось по дате). При поиске по индексу с датой - 130 ответов. Хуже ситуация с редковстречающимся словом, например, 'gravatar' (оно еще хорошо тем, что встречается только в этом году). Это слово встречается всего 33 раза, так что при отсутствии даты в индексе из поиска мы получаем все 33 ответа. При наличии даты в индексе - слово не находится вообще, или находится в 1-2 документах (как повезет).
Насколько я понимаю, в данном случае gin_fuzzy_search_limit ограничил отдельно выборку по дате (фактически выбрар произвольные 10000 сообщений этого года) и отдельно выборку по слову, а затем сделал им 'join', выкинув значительную часть полезных результатов.
Имхо данная проблема сильно ограничивает применимость btree_gin в реальной жизни, по крайней мере в вебе.
Без этого расширения поиск по тексту с учетом дополнительных критериев всегда включает в себя полную выборку по текстовому запросу, которая затем так или иначе фильтруется по дополнительным критериям. С btree_gin можно стазу получить из индекса то что нужно, что (потенциально) быстрее.
Вторая полезная фича поиска - gin_fuzzy_search_limit, она появилась еще в 8.2 (или в 8.3). Этот режим позволяет ограничить выборку по индексу для запросов, которые выдают слишком много ответов, поскольку такие запросы исполняются долго и сильно грузят БД (особенно если потом хочется их всех отранжировать и отсортировать). Фактически это режим "выдачи глупых ответов на глупые запросы". Это значение не должно быть слишком маленьким, нужен еще некоторый запас на фильтрацию по нетекстовым критериям. gin_fuzzy_search_limit задает примерное максимальное число ответов, которое мы хотим получить.
Эксперимент по использованию gin_fuzzy_search_limit совместно с btee_gin по тексту и дате оказался не удачным. Для примера рассмотрим индекс по тексту и дате, и искать будем сообщения за последний год. Тестировалось два запроса - первый по слову "linux". При поиске без даты в индексе за год мы получали ~3000 ответов (gin_fuzzy_search_limit = 10000, остальное отфильтроввывавалось по дате). При поиске по индексу с датой - 130 ответов. Хуже ситуация с редковстречающимся словом, например, 'gravatar' (оно еще хорошо тем, что встречается только в этом году). Это слово встречается всего 33 раза, так что при отсутствии даты в индексе из поиска мы получаем все 33 ответа. При наличии даты в индексе - слово не находится вообще, или находится в 1-2 документах (как повезет).
Насколько я понимаю, в данном случае gin_fuzzy_search_limit ограничил отдельно выборку по дате (фактически выбрар произвольные 10000 сообщений этого года) и отдельно выборку по слову, а затем сделал им 'join', выкинув значительную часть полезных результатов.
Имхо данная проблема сильно ограничивает применимость btree_gin в реальной жизни, по крайней мере в вебе.
