Будет примерно то же самое, что сейчас, только "внутри" GIN, по идее.

"Index Scan using idx_key on table (cost=0.56..993.82 rows=1 width=1910) (actual time=0.328..2.159 rows=2 loops=1)"
"  Index Cond: ((key)::text = '4070281000300043883'::text)"
"  Filter: ((purpose)::text ~~* '%аренды земельного уч%'::text)"
"  Rows Removed by Filter: 407"
"  Buffers: shared hit=108"
"Planning time: 1.051 ms"
"Execution time: 2.202 ms"

Вот план если отключить gin

Это понятно и из прошлого плана

У нас есть подобный индекс но там ts_vector и все летает

Без ilike а ts_query

почему лидер не выбирается?

Вот тебе скажи, без лога то.

))

С авторизацией проблема поди

Я, наверное, пропустил часть обсуждения, но:

> Реакция внешнего инструмента кластеризации на самоизоляцию далеко не мгновенная.

Ну и что? При "самоизоляции" (если не считать bugs) и commit-а не будет, т.е. primary просто "встанет", да и всё.

> Тем более, мастер коммитит в clog независимо от slaves даже при синхронной реплике.

Хмм... о чём именно речь (я как-то сходу не вспомнил)? И, тем не менее, см. выше.

Но, вообще, failover на любую реплику — это disaster, т.е. не стоит его рассматривать иначе, IMHO.

👍

Тьфу, я не то хотел спросить, извините. :(
Какой будет план, если оставить только условие key = '4070281000300043883'?

Хороший, с небольшим  removed BY filter

Ага

shared hit=7 всего

Меня интересуют конкретные оценки, конечно.

не, минимальные настройки не на тот порт сажали

Подождите, откуда там вообще будет filter? Без этого условия же.

Ну без comment он не те данные получит, поэтому...
Ладно буду молчать.