Postgres: bloat, pg_repack и deferred constraints

[@roginvs]

Можно ли использовать такой подход:
— делаем копию базы
— на копии запускаем vacuum full
— подключаем репликацию и применяем WAL логи
— переключаем основную базу на реплику
?

Вижу одну проблему — в теории мощности реплики может не хватить чтобы догнать по WAL основную базу

[@Melkij]

Вы не сможете сделать "подключаем репликацию". Потоковая репликация физического уровня, фактически там прямым текстом сказано "записать такие байты по такому смещению в такой-то файл". А после vacuum full у вас таких файлов и вовсе нет. Зато обработка репликации простая и быстрая штука.

Well, можно соорудить publisher subscriptions из pg10+. При начальном копировании данных будет как раз эффект репака. Только не очень понятно зачем.

PS: сопровождающий pgcompacttable и автор поддержки pg11+ для репака. В работе используем временамт, на грабли deferred ограничений как-то не натыкался. Интересная грабля.

[@n0isy]

А почему вообще на новой таблице не удалить это ограничение (не создавать)? Создать его на момент переименования новой таблицы в старую?

[@nikolai-averin]

Создание ограничения на большой таблице может занять длительное время, в течение которого с таблицей будет невозможно работать.