Nicht selten während einer vollständigen Datenbankwiederherstellung, da dies eine außergewöhnlich große Operation ist. Wenn Sie dies während des normalen Betriebs feststellen, sollten Sie die Einstellung für checkpoint_segmentspermanent erhöhen , genau wie bei den Hinweisen zu den Fehlermeldungen.
Sie könnten sich die Mühe machen, checkpoint_segmentskurz vor der Wiederherstellung eine höhere Einstellung vorzunehmen und diese dann wieder zu senken. Dies ist sogar das, was das Handbuch vorschlägt (einschließlich einer Erklärung) :
Das vorübergehende Erhöhen der checkpoint_segmentsKonfigurationsvariablen kann auch das Laden großer Datenmengen beschleunigen. Dies liegt daran, dass das Laden einer großen Datenmenge in PostgreSQL dazu führt, dass Checkpoints häufiger auftreten als die normale Checkpoint-Häufigkeit (angegeben durch die
checkpoint_timeoutKonfigurationsvariable). Jedes Mal, wenn ein Checkpoint auftritt, müssen alle verschmutzten Seiten auf die Festplatte geschrieben werden. Durch checkpoint_segmentsvorübergehendes Erhöhen
während des Ladens von Massendaten kann die Anzahl der erforderlichen Prüfpunkte verringert werden.
Verwandte Antwort mit mehr Details:
Postgres 9.5
Die kommende neue Version hat einen intelligenteren Ansatz. Zitieren der Beta- Versionshinweise :
Konfigurationsparameter checkpoint_segmentsdurch min_wal_size
und ersetzen max_wal_size(Heikki Linnakangas)
Dies ermöglicht die Zuweisung einer großen Anzahl von WAL-Dateien, ohne sie zu behalten, wenn sie nicht benötigt werden. Daher wurde der Standard für max_wal_size
auf erhöht 1GB.
Abgesehen davon: Die Anzahl der Ansichten ist kaum relevant, diese enthalten keine Daten, nur das "Rezept", dh die Abfrage und einige Attribute der Ansicht. Für die vorliegende Frage ist grundsätzlich nur die Gesamtgröße der Sicherungsdatei von Bedeutung.
