Спасибо!

Не значительный.

О() будет одинаковое.

O - тут как бы не при чем, если скажем оно станет на 40-50% медленне работать на тех же данных

хотя я надеюсь, что в 10-20% уложимся, по крайней мере раньше где-то так получалось

Зря Вы так. ;)
Наоборот, "= ANY ($N)" — это распространённый способ параметризации "IN со списком значений" в PostgreSQL.

O всегда при чём

Коллеги, проясните пож-ста маханизм работы вакуума (теорию  я вроде бы знаю, но что-то видимо упустил). Смотрите - есть довольно большая таблица - 240 Гб данных и 800 Гб индексов. Таблица не партиционирована. По ней запустили Vacuum analyze. Сейчас фаза vacuuming indexes, при этом он пошёл уже по второму кругу, но на этот раз время обработки намного больше: если во время первой итерации обработка конкретного индекса занимала 224 секунды, то во время второй итерации время составило уже 3315 сек. Maintenance_work_mem=4Gb. В документации нашёл следующее - Очистка индексов — VACUUM в настоящее время очищает индексы. Если у таблицы есть какие-либо индексы, эта фаза будет наблюдаться минимум единожды в процессе очистки, после того, как куча будет просканирована полностью. Она может повторяться несколько раз в процессе очистки, если объёма maintenance_work_mem оказывается недостаточно для сохранения всех найденных «мёртвых» кортежей.  Вопросов два - если увеличить этот размер, скажем до 6Gb, будет ли ускорение? И почему настолько разная скорость обработки индекса?

Вообще, есть даже движение за выкидывание ANY из SQL

Я уже, вроде, спрашивал... почему Вы думаете, что оно станет медленнее (какие там текстовые ключи, никто здесь не видел, или я пропустил)?
Можно же просто протестировать, если у Вас запросы есть (меньше чем за полчаса, мне кажется)...

IN <> ANY не взаимозаменяемы.

Например, с IN нельзя проверить равенство оператором LIKE (~).

потому что строковый индекс на бигинтах явно должен быть компактнее, чем строковый, ну и по мелочи там, что инты вообще на регистрах сравниваются, а строки нет

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

Да можно ещё сотню таких же случаев найти, а можно просто не использовать any и тоже жить полноценной жизнью.

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

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

Но это же НЕ РАВЕНСТВО!

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

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

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

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

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

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

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

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

IN <-> ANY :)

А можно просто не использовать IN и жить полноценной жизнью. ;)

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