Вопрос. Есть такая задача, поиск паттернов. То есть мы имеем условия

поиска, чаще не сложное. Например, вопрос, типа: +покер -игра* -ставк -деньг +москва
Для этого либо берут чьи то базы (чаще онлайн) либо сами собирают паттерны с разных источников. Вот у меня такой паттерн на 1+ мрд строк, файл в утф8 занимает 55 гб. Я его загоняю в базу. Внимание. Сейчас поиск grep идёт со скоростью отдачи винчестера, то есть около 130-150 мегабайт в секунду, может чуть дольше. База будет гарантировано постоянно меняться, будут как отмирать какие то старые паттерны, так и новые добавляться. В среднем паттерн 52 байта в утф 8. зы разумеется это сейчас и в файлах оптимизация есть, можно ассии для многих слов. Также может важно, уник слов там 280 млн, но глядя эти слова, я понял, что надо чистить.
Вопрос.
как и какую базу сделать, какие индексы, чтобы поиск был быстрее, чем в grep?

man GIN ts_vector. Теория: У вас будут регулярки. Регулярки разбиваются на триграммы (в базовом варианте, остальные запатентованы), триграммы индексируются через GIN. Примерно это и делается в ts_vector'е. В первом приближении, так как вообще мне такая задача не попадалась.

триграмами я писал. Я же сеошник, мы постоянно с текстами работаем. Триграмы хороши, когда надо срочно живой поиск организовать. Но здесь то мне надо будет весь файл пробежать, к тому же изменчивый. Как вы оцениваете объём этих триграмм? Точно не логичнее как я упираться на уникальные слова, которых всего 280 млн и есть место для чистки?

Я уже сказал что конкретно эту тему не копал. Если понадобится, я-бы сначала прочел про ts_vector, так как знаю что он был придуман для решения конкретно этих вопросов.

то есть кодер детект.

Нет. Я не сказал что пойду и отдам это админу. Я сказал что пойду читать документацию и потом решу эту проблему. В базе. Сам. Это как-раз программист детектед.

уж мне ли профессиональному кодеру не уметь отличать кодеров от программистов :)

Окей. Вы правы.

ага, но немного жаль, что так как в алгоритмах вы также ничего не понимаете, то ответа от вас нет. Триграммы я уже делал, как многие — это тупиковый путь.

Смешно. Я говорю что тему не копал, но при этом дал вектор по которому я-бы пошел, но нет. Окей. Вы правы. Вы победили.

я проиграл. Я то ответ ждал от программиста.

Вы его получили. Вы получили ответ на вопрос что-бы я сделал и как-бы я это сделал в Пг. Но он вас не устроил.

Нанять программиста.

любой кодер не умеет в алгоритмах. Получая задачу, он кодит какое то решение. Смотрит устраивает ли оно заказчика по времени выполнения, например. Если не устраивает, начинает перебирать варианты. В данном случае аглоритмы. Программист, да ещё и с высоким образованием обладает расширенными знанями, натуральный дата саенист. Он может видеть проблемы целиком, разбирал всякие сложные задачи, вместо чтение форумов решает задачи, как илья даёт. Он выдаёт сразу десяток решений на каждую задачу заранее обсчитывая её время выполнения под какие то конфигурации сервера.

где его пОгромиста найти? Вот варстоне слился.

Я сказал — нанять программиста, а не докапываться до программистов с глупыми вопросами!

ааа, программист — это тот человек, который даже пукает только за 50 баксов. А кодер — это тот, кто пишет реальный код с реальными алгоритмами. Спасибо, что пояснили.

Ты какой-то странный. Когда реально нужна помощь, так себя не ведут. К тому же, в ответ на нормальное решение твоей задачи.

На самом деле не совсем -- триграммы это отдельное от ts_vector расшырение (pg_trgm), оно ускоряет другие операцыи (в том числе, на самом деле, LIKE). А индэксы на ts_vector не имеют никакого отношэния к триграммам, там цэлые слова так или иначе участвуют.

Топикстартеру, на самом деле, посоветовал бы тупо сделать ts_vector и GIST индэкс на него. На SSD (любого вида) будет клёвое ускорение.