Comments 5
Спасибо за статью, следил за развитием transparent alter table и тут такое... Подскажите, можно ли использовать для перевода из одной схемы партицирования в другую? Как и в tat, таблица для захвата изменений сделана unlogged: это безопасно? Ещё такое предложение помимо опционального analyze сделать опциональный vacuum, чтобы проставить hint bits.
Спасибо за комментарий.
Если я правильно понял вопрос, речь идет о переводе из схемы партицирования через наследование в декларативное и наоборот, верно?
Таблица для захвата изменений сделана unlogged - основная мысль в том, что таблицы, не проходят через журнал предзаписи, в результате чего такие таблицы работают гораздо быстрее обычных. Нам это позволяет оказывать меньшее влияние на таблицу, которую мы перестраиваем. Для высоконагруженных систем, это может особенно проявляться, когда запись в таблицу замедляется. Однако при сбое или аварийном отключении сервера, лучше почистить вспомогательные таблицы утилиты pg_rebuild_table, с помощью ключа --clean и запустить работу заново.
опциональный vacuum - интересное предложение, постараюсь добавить в ближайших релизах.
Про схему партицирования присоединяюсь к вопросу. Иногда есть необходимость партицировать таблицу "в фоне", либо уйти от не очень удобного ключа партицирования в пользу более эффективного, либо вообще убрать hash-партицирование. Узнал недавно, что hash-партицирование сложно обслуживать, нельзя подменять партиции на лету. А если сделать ещё и бесшовный переход на шардирование по FDW, будет просто бомба.
В копилку идей: можно упорядочивать таблицу не только по PK, но и по другим индексам (фоновый CLUSTER).
В версии 0.1.5 добавлен опциональный параметр make_vacuum_analyze.
Как сэкономить свои нервы и деньги компании на перестроении структуры больших таблиц без простоя в PostgreSQL