Comments 12
Параллельное восстановление даёт кратный прирост, когда нужно пересоздать большие индексы. На 10 гигабайтах этого скорее всего увидеть не удастся.
Plain SQL формат поддерживает сжатие (флаги -Ft -Z одновременно) , это у вас учитывается?
-Ft - это tar формат, который не поддерживает сжатие через -Z
Но сам .tar-формат в тестах есть
Извиняюсь, ошибся, -Fp -Z. Вопрос остаётся тот же.
Проверил, действительно, у plain формата действительно поддерживается сжатие. Причём в разных форматах, начиная с 16-й версии
Этот формат, к сожалению, не проверил. Рискну предположить, что по скорости он чуть медленнее или сравним по скорости с кастмоным форматом во время самого бекапа. Но более долгий во время восстановления
Хех, попробуйте применить plain с перенаправлением в pigz, без шуток. У вас точно откроется второе дыхание для исследования дальше. Спасибо за ваш труд!
:-) Ну как бы - https://github.com/cybernoid/archivemount "стирает проблему" -Fd ...
Ростислав, у вас замечательный проект.
Месяц назад "обезжиривал" инфраструктуру и postgresus пришёлся очень кстати.
Иногда возникает необходимость изучить содержимое буквально одной-двух таблиц из резервной копии. В этом случае формат директории выигрывает у остальных с большим отрывом.
В 2023-м я тоже делал подобные замеры.
Резервные копии PostgreSQL: сравнение скорости pg_dump в разных форматах и с разными уровнями сжатия