Контрольные точки появляются слишком часто во время pg_restore

В PostgreSQL 9.2.2 (32-разрядная версия Windows) у меня есть pg_restoreкоманда, которая систематически выдает в журнал предупреждения о частоте контрольных точек, например:

LOG:  checkpoints are occurring too frequently (17 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Размер базы данных составляет около 3,3 Гб, 112 таблиц / 160 просмотров, и она восстанавливается за 14 минут.

Это нормально для того, чтобы это произошло во время pg_restore?

Нередко во время восстановления всей БД, потому что это исключительно большая операция. Если вы видите это во время нормальной работы, подумайте над постоянным повышением вашей настройки checkpoint_segments, как подсказывает сообщение об ошибке.

Вам может потребоваться установить checkpoint_segmentsболее высокое значение непосредственно перед восстановлением, а затем снова понизить его. Это даже то, что предлагает руководство (включая объяснение) :

Временное увеличение checkpoint_segmentsпеременной конфигурации также может ускорить загрузку больших объемов данных. Это связано с тем, что загрузка большого количества данных в PostgreSQL приводит к тому, что контрольные точки появляются чаще, чем обычная частота контрольных точек (указывается в checkpoint_timeoutпеременной конфигурации). Всякий раз, когда возникает контрольная точка, все грязные страницы должны быть сброшены на диск. checkpoint_segmentsВременное увеличение при массовой загрузке данных позволяет сократить количество необходимых контрольных точек.

Связанный ответ с более подробной информацией:

• Настройка PostgreSQL для производительности записи

Postgres 9,5

Предстоящий новый выпуск имеет более умный подход. Цитируя примечания к выпуску бета-версии :

Заменить параметр конфигурации checkpoint_segmentsна min_wal_size и max_wal_size(Хейкки Линнакангас)

Это позволяет выделить большое количество файлов WAL, не сохраняя их, если они не нужны. Таким образом, значение по умолчанию max_wal_size было увеличено до 1GB.

Кроме того: количество представлений едва уместно, те не содержат никаких данных, только «рецепт», то есть: запрос и некоторые атрибуты представления. Для рассматриваемого вопроса в основном имеет значение только общий размер файла резервной копии.