Если "совсем каждый раз" новые, то вообще не создавайте VIEW, а select'ите результат выборки

Или создайте VIEW без фильтра по ид'ам, а при выборки уже из VIEW накладывайте такой фильтр

Так почему бы не создать SQL function вместо этого view?
Что-то вроде "contacts_count(ids bigint[]) RETURNS TABLE(user_id int, cnt bigint)"?

На самом деле мне этот вариант больше нравится.

Добрый день. Есть 2 среды прод и дев. постгоес почему то строит разные планы запросов для этих сред. почему может быть так?
дев:
explain SELECT ddv.id  FROM draft_data_validation ddv WHERE ddv.draft_id = 8262 AND NOT exists(SELECT 1 FROM draft_data ref WHERE  ref.draft_version_id=8262 and ((ddv.record ->> 'mainGUID') is null or (ddv.record ->> 'mainGUID') = (ref.record ->> 'mainGUID') ) );
                                                              QUERY PLAN  
-----------------------------------------------------------------------------------------------------------------------------------------
Nested Loop Anti Join  (cost=0.71..75.45 rows=1 width=8)
 Join Filter: (((ddv.record ->> 'mainGUID'::text) IS NULL) OR ((ddv.record ->> 'mainGUID'::text) = (ref.record ->> 'mainGUID'::text)))
 ->  Index Scan using draft_data_validation_main_guid_idx on draft_data_validation ddv  (cost=0.29..8.30 rows=1 width=563)
       Index Cond: (draft_id = 8280)
 ->  Index Scan using draft_data_draft_version_id on draft_data ref  (cost=0.42..65.82 rows=98 width=457)
       Index Cond: (draft_version_id = 8280)
прод
unsi=# explain SELECT ddv.id  FROM unsi.draft_data_validation ddv WHERE ddv.draft_id = 23376 AND NOT exists(SELECT 1 FROM unsi.draft_data ref WHERE  ref.draft_version_id=23376 and ((ddv.record ->> 'mainGUID') is null or (ddv.record ->> 'mainGUID') = (ref.record ->> 'mainGUID') ) );
                                                              QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Nested Loop Anti Join  (cost=0.56..28579957500.18 rows=223975 width=8)
  Join Filter: (((ddv.record ->> 'mainGUID'::text) IS NULL) OR ((ddv.record ->> 'mainGUID'::text) = (ref.record ->> 'mainGUID'::text)))
  ->  Seq Scan on draft_data_validation ddv  (cost=0.00..409379.34 rows=1423882 width=375)
        Filter: (draft_id = 23376)
  ->  Materialize  (cost=0.56..539422.54 rows=1700662 width=379)
        ->  Index Scan using draft_data_draft_version_id on draft_data ref  (cost=0.56..446218.23 rows=1700662 width=379)
              Index Cond: (draft_version_id = 23376)
(7 rows)

и там и там были созданы индексы
create index draft_data_validation_main_guid_idx on unsi.draft_data_validation (draft_id, (record ->> 'mainGUID'));
create index draft_data_main_guid_idx on unsi.draft_data (draft_version_id, (record ->> 'mainGUID'));

vacuum analyze был выполнен для draft_data и draft_data_validation

соотношение общего числа записей к числу по выборке
дев
draft_data 738222/3000
draft_data_validation 12116/0

прод
draft_data 6673963\2807963
draft_data_validation 5917660\2807963

Ну так соотношения разные, и планы разные — т.е. что тут удивительного (планы я не читал, если что)?

Ну вот MeiliSearch сама пытается угадать тип, но это система полнотекстового поиска.

Если они будут складывать свои запросы в подконтрольное вам место, то можно будет уведомлять не на каждый чих, а когда меняется нужная этому пользователю таблица / столбец.
Выяснить кто и какие запросы делает можно по журналу запросов, т.е. это автоматизируется, вопрос только в цене.
А вот что делать, если раньше в таблицу писали сделки по акциям и облигациям, а теперь только по акциям, но структуру не трогали? Разве что о новых таблицах писать всем.

Знатоки)

А кто подскажет,  постря в сварме, можно достичь доступности если базу приложения держать на разделах glusterfs, без использования мастер/слейв?

Или нужно использовать родные средства репликации мастер/слейв?

а опишите какую проблему вы пытаетесь решить таким образом?

Коллеги, возможно кто-то экспериментировал.
В 12 версии postgres для кластера Master-Slave с потоковой репликаций кто-нибудь воскрешал старый мастера в stand-by с помощью pg_rewind?
Столкнулся с тем, что после pg_rewind кластер стартуется в режиме standby, но при этом не проигрывает новые изменения.
Может кому известна данная проблема и ее решение?

> можно достичь доступности

Кмк, нет, нельзя. Если контейнер где был проброшен глустерфсный том, внезапно упадет (не синхронизировав все то что было в shared buffers в том), то постгрес запустившись в новом контейнере скорей всего обнаружит неконсистентное состояние, запустить аварийное восстановление и там уже как повезет.

Order by decs заменяет bitmap сканирование на последовательное. Как этого избежать?🤔

а еще в этом чате много олдфагов, и за употребление "постгря" могут вас закидать говном. Старайтесь использовать термин "постгрес".

Если также не хотите чтобы вас закидали говном, покажите:
1. Текст запросов
2. Результаты EXPLAIN (ANALYZE, BUFFERS) для обоих запросов
3. Всё текстом, никаких скриншотов (можно pastebin)

Понял

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

еще возможно понадобится схема таблиц участвующих в запросе - вывод команды \d+ table в psql

😏

¯\_(ツ)_/¯