Полнотекстовый поиск в postgres

можно отключить морфологию в полнотекстовом поиске, но все равно останется токенизация.

Если хочется совсем произвольную подстроку искать (не по токенам), то смотри в сторону расширения pg_trgm

Если хочется совсем произвольную подстроку искать (не по токенам)

Ага.

то смотри в сторону расширения pg_trgm

Триграммы - штука неточная. Искомая строка может даже не присутствовать в найденном тексте:

db=# select similarity('abcdef','abdef');
 similarity
------------
   0.444444

Если, конечно, не задан limit=1, но тогда, если я правильно понимаю, текст должен полностью совпадать с искомой строкой.

можно просто через LIKE искать, поиск будет осуществляться по триграмному индексу при его наличии

Любопытно.

Можно сделать функциональный индекс и тогда like должен будеть искать быстрее.

а нужен поиск вот прям именно в postgres, или просто нужен поиск, а сейчас все данные лежат в postgres?

по какой функции? строка то произвольная

То есть вы хотите индекс по произвольной строке, который мог бы проверять вхождение другой произвольной подстроки и был бы сильно короче оригинальной строки(иначе он бесполезен как индекс)? Так не бывает.

http://www.depesz.com/2011/02/19/waiting-for-9-1-faster-likeilike/

Желательно, чтобы можно было использовать совместно с другими условиями.

иначе он бесполезен как индекс

Это почему?

Круто!

Еще спрошу про экранирование спецсимволов.

... WHERE txt LIKE '%' || $1 || '%'

Достаточно ли заменить в параметре % на \%, _ на \_ и \ на \\ ? Или как это правильно делается?

Потому что если индекс, занимает больше чем сами данные, то проще будет прочитать все данные, чем весь индекс.

Разве обязательно читать весь индекс? Есть всякие штуки вроде бинарного поиска.

Индекса по индексу ведь нет, даже в случае бинарного поиска придётся прочитать кучу блоков индекса. В отличии от данных, конечно, индекс хоть как то упорядочен. Но после чтения индекса, почти в любом случае придётся читать блоки данных, чтобы вытащить остальные колонки.

Возможно, где то это даст ускорение, но очень зависит от задачи. Postgres часто даже от нормального индекса отказывается, потому что считает более выгодным прочитать блоки данных.

Ну и вряд ли возможно построить индекс для вхождения подстроки на основе бинарного дерева.

Желательно, чтобы можно было использовать совместно с другими условиями.

ну это то как раз сделать понятно как: сначала поиском достается диапазон id'шников, а потом вставляется в запрос (WHERE ... AND id IN (....)) уже по основной базе

тут вопрос другой, нет ли ограничений по распуханию инфраструктуры, транзакциям?