Комментарии 5
Кстати, Youtube канал Posgres Professional буквально вчера закидала мои подписки на Youtube курсом DBA2. Они так часто делают всем скопом выкладывают в один день весь курс, который состоит из десятка-двух видео. Там в DBA2 как раз про очистку и автоочистку много полезной информации есть.
Да у них и книги хорошие выложены Книги (postgrespro.ru) с документацией проблем вообще нет.
Про autovacuum была статья на Хабре
Ну и главный источник - 1С ИТС Настройки PostgreSQL для работы с 1С:Предприятием ч.2
Там например описан параметр autovacuum_max_workers
Да статей много, и читая документацию понимаешь что все еще сложнее особенно когда читаешь это PostgreSQL : Документация: 15: 25.1. Регламентная очистка : Компания Postgres Professional
В PostgreSQL семантика транзакций MVCC зависит от возможности сравнения номеров идентификаторов транзакций (XID): версия строки, у которой XID добавившей её транзакции больше, чем XID текущей транзакции, относится «к будущему» и не должна быть видна в текущей транзакции. Однако поскольку идентификаторы транзакций имеют ограниченный размер (32 бита), кластер, работающий долгое время (более 4 миллиардов транзакций) столкнётся с зацикливанием идентификаторов транзакций: счётчик XID прокрутится до нуля, и внезапно транзакции, которые относились к прошлому, окажутся в будущем — это означает, что их результаты станут невидимыми. Одним словом, это катастрофическая потеря данных. (На самом деле данные никуда не пропадают, однако если вы не можете их получить, то это слабое утешение.) Для того чтобы этого избежать, необходимо выполнять очистку для каждой таблицы в каждой базе данных как минимум единожды на два миллиардов транзакций.
Периодическое выполнение очистки решает эту проблему, потому что процедура
VACUUMпомечает строки как замороженные, указывая, что они были вставлены транзакцией, зафиксированной достаточно давно, так что эффект добавляющей транзакции с точки зрения MVCC определённо будет виден во всех текущих и будущих транзакциях
И возникает ощущение что мы боремся не за производительность, а просто предотвращаем ее деградацию. Например борьба за производительность выглядит так - есть запрос, переписали он стал быстрее Лучшее соединение враг хорошего? / Хабр (habr.com) . А с вакуумом - не настроишь и производительность упадет. Депрессивно выглядит, этим явно должны заниматься роботы а не человек. Даже администратору СУБД для корректной настройки нужно в деталях объяснить логику работы с таблицами
Никто не бьётся за прекращение деградации. На самом деле PosttgreSQL достаточно умная штука. Хоть и есть ограничение на число транзакций, она умеет использовать их идентификаторы по кругу. Половина номеров транзакций всегда находится в прошлом, вторая половина в будущем. Строки, которые были добавлены достаточно старыми транзакциями помечаются как замороженные и больше не участвуют в фильтрации при выполнении транзакций, а всегда доступны в любом снимке данных, который использует транзакция. Опять таки, про ранее упомянутый мною DBA2. В нём довольно детально про это рассказывают.
Как эффективно настроить autovacuum в Postgres для 1С