проверку триггерами, как именно предалгаешь?
напомню, что у нас read commited

Вообще, это всё выглядит как-то так, IMHO:

> тут хотелось бюы по минимуму менять схему.

Привязали одну руку за спиной...

> напомню, что у нас read commited

А теперь другую.

> как именно предалгаешь?

И почему-то что-то не так... ;)

Я бы предложил прекратить маяться дурью и либо продолжать использовать MongoDB, либо сделать нормальную реляционную модель и использовать PostgreSQL полноценно.
Я к тому, что если строить на песке, потом тоже всё будет... нехорошо.

и там бигниты из snowflake,  то есть они не короткие

Не понимаю тезиса. Без ANY не обойтись, но можно жить полной жизнью без него.

Теперь понятно. Тем не менее, стоит просто протестировать — данные-то у Вас есть, как я понял.

у вакуума есть рабочая память ( autovacuum_work_mem или же maintenance_work_mem, если первая -1 ). он сканирует таблицу, помещая “мертвые” записи в память. как только память заканчивается, он переходит в вакуумированию индексов, затем он вакуумирует таблицу (в том диапазоне, что прочитал на первом шаге). затем продолжает сканировать таблицу. соответственно, ему надо:
- дать больше памяти (на таблицах схожих с вашими это 1GB)
- понизить autovacuum_vacuum_cost_delay, чтобы быстрее работал за счёт более интенсивного IO (если диски не тянут, то будет больно)

можно смотреть прогресс в pg_stat_progress_vacuum

Текущие значения - maintenance_work_mem = 4Gb, autovacuum_work_mem = 6Gb, autovacuum_vacuum_cost_delay = 10ms, тут что-то ещё можно сделать? Или остаётся пассивно наблюдать?

спасибо за ценный и содержательный ответ.

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

А потом, когда Вы уже выстрелите себе в ногу (и будете орать от боли), Вы то же самое будете повторять? ;(
Или, может, всё-таки не стоит стрелять-то, пока не поздно?

Суть ответа была только в этом, если что.

это все эмоции и лирика :).

Самая длительная транзакция на текущий момент - 44 минуты. Насколько я понял был запущен какой-то скрипт, который потрогал все записи в этой таблице (180 млрд) по крайней мере в логах вакуума возникает сообщение INFO:  scanned index "имя индекса" to remove 178956685 row versions.

Какое-то это число row versions подозрительное, кстати... у Вас там точно не Windows? ;)
Я вот об этом:

> SELECT 178956685*6, 1024*1024*1024;
 1073740110 | 1073741824

Неужто совпадение? Или на самом деле почему-то используется только один гигабайт памяти?

Добрый день!
Помогите пожалуйста🙇🏼‍♀️
Недавно работаю в IT-рекрутинге, попалась вот такая вакансия ( фото с описанием), но кандидатов очень и очень мало.. есть ощущение, что я не того ищу. Резюме с должностью «DBA» или «Администратор баз даных» очень и очень мало😭 Возможно кто-то сможет подсказать, кого именно по таким требованиям нужно искать?