Получается, что комбинации лексем (в целях оптимизации поиска) они не
хранят.
Поэтому чтобы получить данные, в которые входят несколько лексем,
нужно построить пересечение.
Неужто в PG так здорово работают join-ы на больших объемах? Если
судить по восторгам о том как там все здорово сделано?
А кто тебе сказал, что join идет по таблице с данными?
Ты в своей реализации этим ограничен, поскольку у тебя присутствуют
только возможности DSQL.
Ни Lucene, ни, если я правильно понял, PgSQL FTS не ограничены этим -
отбор кандидатов идет по индексу - идет оценка всего полнотекстового
запроса, а не его отдельных термов с последующим джойном "отсеяных"
резалтсетов с реальными даными. В PgSQL для GiST индекса нужна еще
последующая фильтрация, для GIN оно должно работать сразу.
Скажу еще - для того чтоб сделать поддержку запросов типа "wordA NEAR
wordB MAX_DISTANCE 10", то на обычном SQL придется очень сильно
извращатся. Да и для обычных "wordA AND wordB AND wordC" количество
джойнов растет пропорционально (количество записей для проверки -
экспоненциально).
Как workaround ты как раз и пробуешь в словарь добавить целые фразы...
Другие строят свой "индекс" в котором идет оценка всего запроса и
возвращаются только подходящие результаты. При чем, если реализация
нормальная, то автоматически считается score для проиндексированого
документа и hits возвращаются в убывающем порядке.
Роман
