Если я правильно понял вопрос, речь идет о переводе из схемы партицирования через наследование в декларативное и наоборот, верно?
Таблица для захвата изменений сделана unlogged - основная мысль в том, что таблицы, не проходят через журнал предзаписи, в результате чего такие таблицы работают гораздо быстрее обычных. Нам это позволяет оказывать меньшее влияние на таблицу, которую мы перестраиваем. Для высоконагруженных систем, это может особенно проявляться, когда запись в таблицу замедляется. Однако при сбое или аварийном отключении сервера, лучше почистить вспомогательные таблицы утилиты pg_rebuild_table, с помощью ключа --clean и запустить работу заново.
опциональный vacuum - интересное предложение, постараюсь добавить в ближайших релизах.
Спасибо за отличную статью!
Планируете ли опубликовать данное хозяйство в общий доступ?
Планируете ли рассказать, как эти метрики собираются в вашей системе?
Для хранения журнала лога СУБД используете loki?
В версии 0.1.5 добавлен опциональный параметр make_vacuum_analyze.
Спасибо за идеи, добавлю в список задач.
Спасибо за комментарий.
Если я правильно понял вопрос, речь идет о переводе из схемы партицирования через наследование в декларативное и наоборот, верно?
Таблица для захвата изменений сделана unlogged - основная мысль в том, что таблицы, не проходят через журнал предзаписи, в результате чего такие таблицы работают гораздо быстрее обычных. Нам это позволяет оказывать меньшее влияние на таблицу, которую мы перестраиваем. Для высоконагруженных систем, это может особенно проявляться, когда запись в таблицу замедляется. Однако при сбое или аварийном отключении сервера, лучше почистить вспомогательные таблицы утилиты pg_rebuild_table, с помощью ключа --clean и запустить работу заново.
опциональный vacuum - интересное предложение, постараюсь добавить в ближайших релизах.