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

select count(*) from fileattachment where issueid not in (select id from jiraissue);

Никакой. Не используйте NOT IN, см. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_NOT_IN

Это, конечно, прекрасно... в теории.
Но на практике, как мне кажется, сделать это не так просто, и отнимает у выполняющего куда больше времени.

проблема не только в задержках, но и в том, что вакуум не считает нужным что-то делать. поэтому:
- понижаем на порядок scale_factor
- понижаем до 10 или до 5 cost_delay (зависит от дисков)
- руками вакуумируем самые проблемные (большие) таблицы
- проверяем “возраст” таблиц, вакуумируем те, что близки к anti-wraparround
- после стабилизации, ставим cost_delay в районе 2-5
- мониторим “наполненность” воркеров вакуума (если заняты все какое-то время — повод смотреть настройки)

Главное чтобы прод гладко работал =)

select count(*) from fileattachment where issueid not in (select id from jiraissue);

from fileattachment left join jiraissue дальше думать головой и соображать мозгами.

ok, 🙂 пойду создам задачу на переписку ORM

Тогда легче купить адекватное "железо", чем выбрасывать тратить деньги на зарплату DBA, чтобы он дни и ночи проводил в обнимку с сервером. ;)

Нормальные ОРМ умеют в raw-SQL.

Just FYI, позиция проекта PostgreSQL по поводу бездарно написанных ORM сводится к тому, что это их проблемы.
И её изменений, к счастью, не предвидится. ;)

Тут зависит от ситуации, как я понимаю

Если страница которую мы хотим обработать в shared_memory отсутствует, то ее надо прочитать это - cllean, нужно создать новую страницу, испачкать ее и засинкать на диск

Если это данные которые все еще есть, и они в shared_memory и на диске одинаковые, то автовакуум должен испачкать страницу и засинкать это на диск

Если данные в shared_memory и на диске не одинаковые - страница уже испачкана до нас - нужно засинкать, снова испачкать и засинкать

Так же все?

Я сильно не думал, но разве это не другая проблема?
Я имел в виду ситуацию, когда autovacuum "вовсю" (согласно текущим настройкам) работает, но не справляется.

и тогда получается первый случай это miss
второй - hit
третий - durty

Почти, но нет. Короче:
1. После работы vacuum страница всегда грязная (но она могла быть такой и до).
2. "Синкать" что-то куда-то — это не задача vacuum, и он этим не занимается.

> нужно создать новую страницу, испачкать ее и засинкать на диск

Просто считать. По sync — выше.

> нужно засинкать, снова испачкать и засинкать

Как раз и нет, это самый дешёвый случай — была грязная и такой и останется, sync чего-то — не проблема vacuum.

<Шутка про то, что один ssd заменяет двух dba>

А есть ли вообще смысл так глубоко закапываться в тюнинг автовакуума "просто штоб было"? То есть пока проблем не видно. Кажется, нету.

Добрый день! кто-нибудь сталкивался с таким?: постгрес нагружается по CPU (делит ресурсы с другими тачками в vmware), после освобождения ресурсов продолжает тупить.. решается рестартом сервиса.. мб планировщик как-то запоминает что CPU "плохой" и продолжает в том же режиме работать? что можно дернуть без рестарта?

тогда, если случай когда страница уже грязная, самый дешевый, почему в дефолтных параметрах он стоит как самый дорогой?

Не стоит! Процитируйте мне это (мне уже начинает казаться, что Вы где-то не то и не там читаете, честное слово).

что процитировать?
Я сейчас смотрю на конфиг постгреса в который эти параметры приехали с пакетом