Я и говорю, колдовство.

я думаю, все подобные подозрительные должны отправляться на мастер
по дефолту

а если всё на API построено, то RO не скейлится никак 🙁

так это, ручками отправлять:)

Кто его знает )) Может и без него неплохо.

У нас на api пару сервисов. Распределение на стороне приложения, и все ок.

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

И я об этом

Работал с другими СУБД, все ноды могли писать. Не лез под капот, честно скажу, может и было реализовано оно в тех СУБД похабно, вы ведь на это намекаете?))

Выше это "предложение для бедных"

Коллеги, столкнулся с такой проблемой : есть таблица с колонкой comment varchar, по которой построен триграмный GIN индекс (для поиска по маске %%). Так же есть индекс на некий ключ(не уникальный но довольно селективный). При запросе SELECT * FROM TABLE WHERE KEY = XXX AND COMMENT ILIKE '%wazzap%' , ПГ выбирает план из двух BITMAP index scan и операцией AND. Проблемы в том что индекс триграммный гигантский (200ГБ), а ПГ считает, что сходить извлечь из него пару сотен строк это легко, однако в реале это оборачивается в десятки минут. Если просто удалить\отключить GIN индекс, то ПГ просто отбирает значения по первому условию (KEY, пара тысяч строк)- наклдывает фильтр и вуаля. Результат за миллисекунды. Статистика обновлена. Как постгресу сказать что поход в 200ГБ GIN - дорого?

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

А добавь поле key в gin индекс?
Или это только rum умеет, не помню уже.

Не даёт.. Составной с 11 версии вроде.. И не уверен что можно комбинировать btree и gin

"довольно селективный" т. Е. По фильтру comments не много отбрасывает?

Можно btree_gin_ops или как его.. В доку в общем.

Либо подозреваю можно cte по key.
Но я сейчас насоветую...

А план можете показать?

Здесь же и без плана видно что болит

Мне пока не видно. ;) Может, всё-таки удастся подправить оценки, кто знает...