> > Неужто в PG так здорово работают join-ы на больших объемах? Если > > судить по восторгам о том как там все здорово сделано? > > Да, еще (в догонку к первому посту, которого почему-то не видно): не > знаю как GIN делает, но Lucene еще хранит информацию о частоте > использования лексемы. Таким образом можно на начальном этапе поиска > использовать только те лексемы, которые не слишком часто встречаются и > являются наиболее релевантными для поиска.
Частота у меня тоже есть. И статистика по общему числу использования лексемы - тоже. Это пересчитывается каждую ночь и юзается для построения наиболее легковестного запроса. Суть моего вопроса не в этом. Вот у меня есть индексная таблица с записями <ID-лексемы> <ID-объекта> В PG (у GIN-а) тоже такое есть. Если у объекта 10 уникальных лексем, у меня добавиться десять записей. Судя по описанию GIN - у них тоже. Теперь мне нужно выбрать объекты у которых есть 3 лексемы. Я делаю пересение трех выборок по <ID-объекта> из индексной таблицы для первой, второй и третьей лексемы. То есть два джоина. На 15 лимонах записей - ощутимые тормоза. Индексы для этого запроса с двумя join-ами юзаются путевые. Значит тормоза - из самого факта существования джоина. А как в PG как это делается? То есть как махом выбрать объекты у которых мои три лексемы? Что конкретно представляет из себя их чудо индекс для точного полнотекстового поиска? Коваленко Дмитрий.
