Готовим полнотекстовый поиск в Postgres. Часть 1

Хорошая статья, хочу лишь добавить что в случае когда тексты написаны на разных языках, нужно добавить колонку типа REGCONFIG в которой будет храниться язык например:
ALTER TABLE documents_document ADD COLUMN lang REGCONFIG NOT NULL DEFAULT 'russian'::regconfig;
индекс:
CREATE INDEX idx_gin_document
ON documents_document
USING gin (to_tsvector( lang, «document_text»));

или
добавить колонку lang типа VARCHAR:
ALTER TABLE documents_document ADD COLUMN lang VARCHAR NOT NULL DEFAULT 'russian';
индекс:
CREATE INDEX idx_gin_document
ON documents_document
USING gin (to_tsvector( lang::REGCONFIG, «document_text»));

Насколько актуальны по Вашему мнению полнотекстовые индексы без нечеткого поиска («с опечатками»)? Их по-прежнему имеет смысл использовать например в веб-приложениях?

Спасибо, интересно.
Ждем продолжения.

Пробовал использовать полнотекстовый поиск на postgresql, но затем оказалось удачнее подключить Lucene к JPA, все культурно подключается и индексируется, поиск работает быстро.

Спасибо за статью!
Кстати, если создать индекс с конфигурацией russian

CREATE INDEX idx_gin_document 
ON documents_document 
USING gin (to_tsvector('russian', "document_text"));

И выполнять запрос без

to_tsvector("document_text"), plainto_tsquery('запрос')

То индекс использоваться не будет

Странно, я очень давно пользовался FTS в PostgreSQL, но в моем случае, после миграции с PostgresSQL FTS на SphinxSearch, который индексировал Postgres, скорость поиска выросла значительно, а нагрузка на базу данных существенно упала.

Из всех деталей помню только, что тогда переход на SphinxSearch позволил спать спокойно как минимум несколько следующих месяцев.

Правда это было в стародавние времена (едва ли не 10 лет назад, даже не помню, какая тогда версия Postgres была, наверное 8), и наверное, большое влияние оказывает размер документов и характер доступа к ним.