У меня выключен автовакуум, вместо этого по ночам раз в сутки гоняется VACUUM; ANALYZE;
За день базы не успевают критично распухать, народу немного.

VACUUM FULL не применяю, т.к. результат практически одинаков с обычным VACUUM, зато огромная нагрузка на саму базу и сеть при синхронизации на реплику.

Однако же пошел искать, куда место делось, топ-1 стоит pg_catalog.pg_attribute.
Выяснилось, что там постгрес хранит данные о всех таблицах, в т.ч. временных, а 1с временные таблицы использует (создает и удаляет) ну очень много.

Обычный vacuum почему-то не уменьшает размер конкретно этой таблицы.

Добавил к еженощным процедурам:
VACUUM FULL pg_catalog.pg_attribute;

FULL для примера сократил с 29GB до 111MB, вся база была 85GB, стала 55GB

Какие еще полезные процедуры знаете?

DROP DATABASE тоже может сильно уменьшить размер базы
(шутка)

зачем уменьшать размер таблицы, если он она опять вырастет. но коли обрезали - соберите статистику роста.

Обычно автовакуум все же не отключают, а настраивают его параметры под свой профиль нагрузки. Это более эффективно.
А вот борьба с bloat: https://habr.com/ru/company/miro/blog/499444/

При настроенном автовакууме, кстати, bloat гораздо меньше.

В статье описывается работа с pg_repack, но мне больше понравилась идея pg_compact и типа него. Там просто последние записи переносятся в пустые места, чтобы пустое место образовалось в конце и тогда его легко срежет обычный вакуум (без лишних локов и резких телодвижений). Я давно уже с постгри не работаю, да и когда работал - не сказать что глубоко разбирался. Может, что более интересное есть на текущий момент.

Вообще, плотнее всего с 1С на постгри в суровом продакшене вроде работал Лустин и его команда из silverbulleters.
У них было много наработок по обслуживанию и повышению производительности. Можно попробовать поискать доступные материалы.

(2) > зачем уменьшать размер таблицы, если он она опять вырастет
в пухлую таблицу вставлять новые записи в целом дороже, чем в худенькую, а вставляются они туда при каждом открытии документа, подборе в поле ввода и т.п.

(2) > коли обрезали - соберите статистику роста
за 6 часов размер вырос с 111 MB до 227 MB, при этом в базе работают три калеки

(3) > настраивают его параметры под свой профиль нагрузки
полностью согласен. у меня профиль нагрузки - три калеки, оптимальный профиль - выкл и по крону раз в день

(5) все это здорово, но я думаю такими вещами стоит заморачиваться, когда приложение предсказуемо и пользуется базой как базой, а не второй оперативной памятью
ну т.е. какбе для 1с это не очень актуально, штатный autovacuum средненько, но справится