рестарт же тут подразумевается бд в целом, не pg_reload_conf()?

да, полный рестарт - у этого параметра контекст postmaster

Привет! Подскажите, пожалуйста, что я делаю не так (или как лучше делать).
Есть две связанные таблицы (связь один ко многим), по колонкам которых нужно искать по ilike. Нужные колонки проиндексировал gin индексом. Но если в where я указываю только колонки одной из таблиц - gin индексы отлично отрабатывают (смотрел explain analyze), если колонки из двух сразу - ни один gin индекс, кроме проиндексированного внешнего ключа, не используется. Как это исправить?

Покажите версию PostgreSQL, запросы, планы (EXPLAIN (ANALYZE, BUFFERS)) и \d каждой таблицы, в идеале.

Всем привет, вопрос общего порядка. Не могу найти статьи и пр. с темой "почему вам НЕ нужен <условный> patroni".
Было упоминание этой идеи на PGConf.Russia 2020 у Василия Пучкова, бывало тут в чате обсуждали, ну и мои наблюдения часть вещей подтверждают.
Начал было накидывать доводы почему внедрение HA может принести больше минусов, чем плюсов, но на каждый находится и противодовод.
Не попадалась ли кому полноценная оценка плюсов-минусов?

1) PostgreSQL 11.10
2) https://justpaste.it/328tr

А при "SET enable_seqscan = off;" какой план второго запроса (где две таблицы) получается?

Точно такой же

Не может быть. Тогда там оценки обязаны быть другие, по крайней мере.

Вы не выполнили  "SET enable_seqscan = off;".

Хм, почему-то действительно не подтянулся. Исправил инфу по старой ссылке

На первый взгляд похоже на то, что индекс тут не используется по какой-то "принципиальной" причине, т.е. дело не в оценках...

А почему тут:

CREATE INDEX index_ozp_card_registry_identity_coument_issuer ON dentity_document USING gin (issuer gin_trgm_ops);
ALTER TABLE dentity_document ADD CONSTRAINT identity_document_to_demand FOREIGN KEY (demand_id) REFERENCES demand(id) ON DELETE CASCADE;

dentity вместо identity? Может, таблица не та? ;)

CREATE INDEX index_ozp_card_registry_identity_coument_issuer ON dentity_document USING gin (issuer gin_trgm_ops);
ALTER TABLE dentity_document ADD CONSTRAINT identity_document_to_demand FOREIGN KEY (demand_id) REFERENCES demand(id) ON DELETE CASCADE;

Не, та. Это, видимо, я криво отредачил)

(Всмотревшись в условие) Так тут нельзя использовать условие (d.last_name ILIKE '%asd%' OR d.first_name ILIKE '%asd%') прямо на таблице demand — результат получится некорректный. Поэтому индексы мимо, PostgreSQL тут всё правильно делает.
Я имею в виду такой пример:

d.id  id.demand_id  d.last_name  d.first_name  id.issuer 
 1       1            'NOSD'      'NOSD'        'asd'

Так вот эта строка из demand должна остаться в выборке, отфильтровать её по индексам нельзя (некорректно) →  они бесполезны. Вот и всё.

Все из-за условия or?

Хм, видимо, я не понимаю, как индексы под капотом работают

Спасибо!

Из-за того, что именно такое условие + LEFT JOIN нельзя "разобрать" на составляющие — это логически некорректно.
Т.е. из demand нужны все записи, как ни крути (PostgreSQL, кстати, "крутит", превращая LEFT JOIN в Hash Right Join — но логика от этого не меняется).
А Вы точно хотели именно такую выборку (чтобы подобные строки попадали)?