Під PostgreSQL 9.2.2 (біт Windows 32) у мене є 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тимчасовому збільшенні під час масових навантажень даних кількість необхідних контрольних пунктів може бути зменшена.
Відповідна відповідь з більш детальною інформацією:
Новий реліз має розумніший підхід. Цитуючи примітки до бета-версії :
Замініть параметр конфігурації
checkpoint_segmentsнаmin_wal_sizeіmax_wal_size(Heikki Linnakangas)Це дозволяє виділити велику кількість файлів WAL, не зберігаючи їх, якщо вони не потрібні. Таким чином, за замовчуванням
max_wal_sizeбуло збільшено до1GB.
Убік: кількість переглядів ледь є релевантною, вони не містять жодних даних, лише "рецепт", тобто: запит та деякі атрибути представлення даних. Що стосується питання, важливим є лише загальний розмір файлу резервної копії.