Автоочистка и секционированные таблицы
Postgres doc говорит, что секционированные таблицы не обрабатываются автоочисткой. Но все же я вижу, что столбец last_autovacuum из pg_stat_user_tables заполнен последними временными метками для живых разделов.
Означает ли это, что эти временные метки устанавливаются фоновым рабочим процессом, который только предотвращает перенос идентификатора транзакции без фактического выполнения ANALYZE&VACUUM? Или что-то еще, что может их заполнить?
Кроме того, учитывая, что разделы большие и достаточно активные, должен ли я вручную запускать ANALYZE и VACUUM на этих разделах? Если да, имеет ли значение порядок?
ОБНОВИТЬ
Я пытаюсь уточнить, благодаря данным комментариям.
Взятие этого вакуума должно работать на партиции так же, как и на обычную таблицу, что может быть причиной гораздо более быстрого роста занимаемого дискового пространства после партиции? До разделения это была почти линейная функция количества записей.
Что также сбивает с толку, при поиске запущенных процессов автоочистки я вижу, что те, которые связаны с разделами, обозначены как «для предотвращения переноса», а другие - нет. Это абсолютное совпадение или есть что проверить?
Документация описывает секционированную таблицу скорее как виртуальную сущность без собственного хранилища. Какой смысл указывать, что он не пропылесосен?
@FrankHeikens, прямо здесь: postgresql.org/docs/current/routine-vacuuming.html Многораздельные таблицы не обрабатываются автоочисткой. Статистику следует собирать, запуская АНАЛИЗ вручную при первом ее заполнении и повторно всякий раз, когда распределение данных в ее разделах значительно изменяется.
Разделы очищаются и анализируются как обычно. Это не только родительская таблица.
Раздел очищается, когда данные изменились, когда в этом есть необходимость. Это не делается из-за вакуума в родителях. Это разные таблицы. И да, один может быть родителем, а другой ребенком
@FrankHeikens, большое спасибо за ваши комментарии. Могу я попросить вас взглянуть на обновление выше?
@jjanes большое спасибо за ваши комментарии. Могу я попросить вас взглянуть на обновление выше?
Для номера 2 нам нужно гораздо больше информации, а номер 3 противоположен тому, что я могу найти в документации.
@FrankHeikens, цитата из документации (postgresql.org/docs/current/ddl-partitioning.html): сама секционированная таблица — это «виртуальная» таблица, не имеющая собственного хранилища. Вместо этого хранилище принадлежит разделам, которые в остальном являются обычными таблицами, связанными с секционированной таблицей.
Родительская таблица пустая, виртуальная. Но все еще нуждается в вакууме время от времени, чтобы избежать обертывания. автоматический пылесос позаботится об этом. Разделы будут чаще очищаться при изменении данных. Но какую проблему вы пытаетесь решить?
@FrankHeikens, (1), гораздо более быстрый рост занимаемого дискового пространства по сравнению с неразделенной версией.
Тогда вы должны задать вопрос об этой проблеме и дать нам некоторую информацию
Какой раздел растет? Все они? Используйте pgstattuple, чтобы увидеть, много ли мертвого или свободного места. Возможно, кто-то принял разделение в ожидании значительного увеличения активности, и теперь это увеличение произошло.
Ответы 1
Утверждение из документации верно, но вводит в заблуждение. Autovacuum обрабатывает не саму секционированную таблицу, а разделы, которые являются обычными таблицами PostgreSQL. Итак, мертвые кортежи удаляются, карта видимости обновляется и так далее. Короче говоря, в отношении уборки не о чем беспокоиться. Помните, что сама секционированная таблица не содержит никаких данных!
Документация предупреждает вас о том, что ANALYZE. Autovacuum также запускает автоматические задания ANALYZE для сбора точной статистики таблиц. Это будет нормально работать на секциях, но для самой секционированной таблицы статистика не собирается, поэтому вам нужно запустить ANALYZE вручную для секционированной таблицы, чтобы получить эти данные. На практике я считаю, что это не проблема, так как оптимизатор все равно генерирует планы для каждого отдельного раздела, и там у него есть точная статистика.
Спасибо! Есть ли возможность исправить/дополнить эту часть документа? Я совершенно уверен, что все мои коллеги прочитали его так же, т.е. неправильно.
Я предложил патч документации.
Где вы нашли эту информацию? Каждый стол будет пропылесосен, когда возникнет необходимость