Пока непонятно. :) Жили без ручного вакуума все время, тут решили пару дней назад попробовать "а что будет", пока визуально сложно сказать есть ли профит, хуже не стало точно

Смущает, что он молотит полчаса, то есть выходит, что автовакуум приходит как-то совсем непонятно когда и как

Видимо когда используеш функцию из дашборда пгадмина он так криво выдает, вот вручную запрос сделал - https://explain.depesz.com/s/JXzr

Судя по вашему профилю нагрузки auto vacuum analyze и так приходит раз в сутки-трое

Та настройки которые вы показали - это параметры запуска (startup triggers) для autovacuum. Агрессивность его работы настраивается параметрами autovacuum_vacuum_cost_delay и autovacuum_vacuum_cost_limit

Возможно, в списке запросов его иногда глазами видно. Сейчас хочется понять для себя стоит ли вообще что-то здесь делать или без прямого доступа к субд проще сразу плюнуть и жить так дальше. Есть варианты убрать  ручные запуски, попробовать собирать статистику по времени работы процессов, которые пишут/читают, потом вернуть ручной вакуум и посмотреть что поменяется. Но совершенно не ясно что делать, если окажется, что польза от ручного вакуума есть - пытаться его руками запускать как-то более умно, чем раз в сутки, или просить менять конфиг.

<pg_settings name="autovacuum_vacuum_cost_delay" value="20"/>
   <pg_settings name="autovacuum_vacuum_cost_limit" value="2400"/>

Отличаются от параметров по умолчанию.

Постараться уложить всю таблицу в память. И что гораздо более эффективно - оптимизировать доступ к ней, но в коробочном приложении это сложно.

Плюс сейчас из чувства паранойи ручной вакуум никогда не запускается параллельно с пишущими процессами, они ждут пока вакуум закончит. Это не очень удобно, т.к. скорость появления данных во время запуска вакуума - 0. Есть ли вероятность, что запись деградирует при параллельно работющем вакууме?

На ближайшее время не вариант, мало того что коробка, так и инфраструктура вся у вендора. Потому и приходится заниматься диагностикой через гланды.

Да уж. Может, им bug report написать (такие планы практически бесполезны)?

Что там с autovacuum в базе? Для crmUsers_amocrm_v3 давно выполнялся, например (может, она очень часто обновляется)?

А так — тут можно попробовать два варианта, в принципе.
1. Тот, что Вы предложили:

CREATE INDEX ON contacts (accountId) WHERE unanswered > 0 AND NOT deleted;

2. Или вот так:

CREATE INDEX ON  crmUsers_amocrm_v3(integrationId, chatType, chatId); -- Порядок полей не так уж важен для *этого* запроса

Забыл написать — а что чтений так много? RAM на сервере не хватает? Или настройки "кривые"?

"Стандартный" подход — менять конфиг. В конце концов, для решения этой задачи autovacuum и предназначен, т.е. идея в том, что если он не справляется, стоит его настраивать, а не костыли городить. ;)

CREATE INDEX ON contacts (accountId) WHERE unanswered > 0 AND NOT deleted;

CREATE INDEX ON  crmUsers_amocrm_v3(integrationId, chatType, chatId); -- Порядок полей не так уж важен для *этого* запроса

Да, crmUsers_amocrm_v3 часто обновляется, попробую с индексами. Насчет железа должно хватать, но этот вопрос надо уточнить. В любом случае спасибо за ответ. Если получу какие-то результаты, напишу)

> железа должно хватать, но этот вопрос надо уточнить.

Но не хватает, как видно по плану. ;)

А на что менять? Кажется, что требовать обрабатывать таблицу после каждых, скажем, 10К записей - может оказаться убийственно в момент, когда придет суточная пачка в миллионы строк - писатель будет конфликтовать с автовакуумом. Или нет? В документации как-то не ясно что случится, когда запись пачками еще идет, а автовакуум уже решил запускаться

Стремно, что в какой-то момент придет одновременно запись, чтение клиентами и автовакуум и все это радостно погибнет уперевшись в IO

Не будет он конфликтовать. Вообще, "ужасы" vacuum сильно преувеличены. ;)
Какая это версия PostgreSQL, кстати?

11

Проблема в том, что альтернатива — "чем меньше выполняется vacuum, тем больше нужен vacuum" (таблицы-то растут).
И ни писателей, ни читателей это может не порадовать. ;)