pg_restore中にチェックポイントが頻繁に発生している
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.3Gb、テーブル数は112、ビュー数は160で、復元は約14分です。
pg_restoreの実行中に発生するのは正常ですか？
DB全体の復元中は珍しいことではありません。これは非常に大きな操作であるためです。通常の操作中にこれが表示される場合は、エラーメッセージのヒントと同様に、checkpoint_segmentsの設定を永続的に上げることを検討してください。
復元の直前にcheckpoint_segmentsを高く設定してから、もう一度低く設定するという問題に直面する可能性があります。これは マニュアルが示唆する（説明を含む） ：
一時的に
checkpoint_segments構成変数を増やすと、大量のデータの読み込みが速くなります。これは、大量のデータをPostgreSQLにロードすると、チェックポイントが通常のチェックポイント頻度（checkpoint_timeout構成変数で指定）よりも頻繁に発生するためです。チェックポイントが発生するたびに、すべてのダーティページをディスクにフラッシュする必要があります。データの一括読み込み中にcheckpoint_segmentsを一時的に増やすことで、必要なチェックポイントの数を減らすことができます。
詳細と関連する回答：
Postgres 9.5
今後の新しいリリースでは、よりスマートなアプローチが採用されています。 ベータリリースノート を引用：
構成パラメーター
checkpoint_segmentsをmin_wal_sizeおよびmax_wal_sizeに置き換えます（Heikki Linnakangas）これにより、大量のWALファイルが不要な場合に、それらを保持せずに割り当てることができます。したがって、
max_wal_sizeのデフォルトは1GBに増えました。
補足：ビューの数はほとんど関係がなく、データは含まれていません。「レシピ」、つまりビューのクエリといくつかの属性のみが含まれています。当面の問題については、基本的にはバックアップファイルの合計サイズのみが重要です。