Наполнение словаря - это философский выбор. Мое мнение, что нужно сделать словарь на основе n-gram переменной длины и индексировать всё, а при поиске задавать степень соответствия.

Да это же не словарь, в таком случае... нет?
Т.е. сгенерируйте все сочетания букв длины 1, 2, 3... N — и вот он "словарь".
Или я не понял, что Вы имели в виду?

Всем привет
есть табличка в базе,в ней есть колонки типа time со значениями "00:00:00",но есть записи и с другими временами
в orm колонки просто задаются
time_start = Column(Time)

при запросе count считаются все значения
а при запросе на получение  я получаю строки,у которых время не равно 00:00:00,хотя никаких фильтров на это нет
что я делаю не так?

Нужно посмотреть / проверить запросы и данные в psql, для начала, я думаю.

Словарь - это любая программа, которая из входа что-то генерит, то есть для каждого слова можно выдать упорядоченный список ngram

Никто не знает, кроме Вас, какой SQL-запрос делает эта неизвестная ORM

При поиске матчить эти списки.

Но специфические словари терминов конечно тоже нужны.

Нет, подождите. :)
Это обычные n-gramms, такое можно "на коленке запилить" в PostgreSQL хоть сейчас... но к настоящим орфографическим словарям это не имеет никакого отношения...
Т.е. Вы имеете в виду, что настоящие словари не нужны?

> Но специфические словари терминов конечно тоже нужны.

Хмм... но зачем, учитывая вышенаписанное?

Ярослав, просто все зависит от задачи. Я не видел моральной идеального морфологического словаря. Мы проектировали fts как возможность матчинга запроса и документов с возможностью ранжирования, конкретную реализацию со словарями и конфигурациями можно рассматривать как одну из возможных. На самом деле основное это два типа данных и оператор для них, дальше все можно делать руками, т.е., самому делать tsquery, tsvector, хоть во внешнем клиенте.

Это я всё умозрительно понимаю (реального опыта с FTS у меня мало), но мне кажется, что подход с n-граммами в реальности будет плох.

Вот для примера (первое, что пришло в голову): при поиске по слову "меч" так можно выдавать "мечусь" (словоформу "далёкого" по n-граммам "метаться"), а вот "брошь" и "брошу" — почти одно и тоже.

Так вот меня как раз интересует, какими должны быть словари, чтобы "русский" FTS был качественным на практике.

> Так вот меня как раз интересует, какими должны быть словари, чтобы "русский" FTS был качественным на практике.
Тогда нужно стремиться к полноте словарей, но проблему омонимии они не решат - Путин, путин, Путина, путина ? Я не в курсе, кто-нибудь вообще занимается поддержкой машинной морфологии русского языка, имеется ввиду открытой. Я вижу только aot.ru

> Тогда нужно стремиться к полноте словарей,

Почему нужно-то? Вот то, что я написал про совпадающие с "левыми" словами опечатки — как в идеале должен к ним относиться FTS?

> но проблему омонимии они не решат - Путин, путин, Путина, путина ?

Ну так это реальная проблема (в самом языке), а не проблема качества словарей.

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

А никто, насколько я знаю (по крайней мере, я больше вообще не нашёл ни одного активного проекта). :(
Причём то, что делает AOT, мне крайне не нравится — я вижу, что туда просто внесено много опечаток; кроме того, словарь  набит топонимами, фамилиями, диалектизмами, устаревшими словами и "редкими" терминами.
Даже для его, по идее, основной цели (проверки правописания) это всё совсем не хорошо.

А, и ещё про этот "прекрасный" словарь — заметно, что он сделан по принципу "да ладно, и так сойдёт!" — к примеру, нередко вместо основы и правил словоизменения сделано вот так (реальный пример):

аркаден аркадна аркадная аркадно аркадного аркадное аркадной аркадном аркадному
аркадную аркадны аркадные аркадный аркадным аркадными аркадных

Т.е. для проверки правописания это сойдёт, а вот для FTS получается, что каждая форма здесь — основа, т.е. "аркадному" и "аркадный" — это совершенно разные слова.

Добрый день. В ноябре этого года постгрес 9.6 переходит в неподдерживаемую версию. На какую версию посоветуете мигрировать?

Поднял shared_buffers до 36 Гб при оперативе 48Гб. Получил гораздо лучше результаты, чем при 8-12 Гб.
Но не даёт мне покоя мысль про выстрел в ногу )))

Мой кейс - это аналитическая БД. Две денормализованных витрины 10 Гб и 12 Гб. Обновление витрин небольшими порциями 1 раз в 3 часа (DELETE + INSERT).
К витринам подключена BI-система, которая шлет множество запросов в БД (отчеты с Live Connection, 10-12 сессий на пользователя). Каждый запрос обернут в курсор with hold (пробую бороться с этим, пока оживил запросы поднятием сursor_tuple_fraction до 0.9). Изначально всё это хозяйство жило в GreenPlum, но осилить поток в сотни мелких запросов не вышло.

Какие риски 75% shared_buffers в моем случае?

13.2 выйдет 11 февраля, на неё и переходить

аркаден аркадна аркадная аркадно аркадного аркадное аркадной аркадном аркадному
аркадную аркадны аркадные аркадный аркадным аркадными аркадных

Мы взяли ispell-кие словари для морфологии от бедности. Буду рад, если кто возьмется за создание нормального морфологического словаря.

На новую. Но там вся конфигурация и файлы попереименованы, будьте внимательны.

1. аналитическим запросам нужна память. нужно следить, чтобы shared_buffers + сессии * work_mem было бы в пределах доступной памяти, чтобы не призвать OOM.
2. вам следует посмотреть как себя чувствуют чекпойнты при таких shared_buffers, у меня был кейс, когда дискам и системе было легче при низком значении shared_buffers, т.к. запросы всё равно много читали с дисков при любых shared_buffers