Ce n'est pas rare lors d'une restauration de base de données entière car c'est une opération exceptionnellement énorme. Si vous voyez cela pendant le fonctionnement normal, envisagez d'augmenter votre réglage de checkpoint_segmentsfaçon permanente, tout comme les conseils de message d'erreur.
Vous pourriez avoir la difficulté de régler checkpoint_segmentsplus haut juste avant la restauration, puis de le baisser à nouveau. C'est même ce que le manuel suggère (y compris une explication) :
L'augmentation temporaire de la checkpoint_segmentsvariable de configuration peut également accélérer le chargement de données volumineuses. En effet, le chargement d'une grande quantité de données dans PostgreSQL provoquera des points de contrôle plus fréquents que la fréquence normale des points de contrôle (spécifiée par la
checkpoint_timeoutvariable de configuration). Chaque fois qu'un point de contrôle se produit, toutes les pages sales doivent être vidées sur le disque. En augmentant
checkpoint_segmentstemporairement pendant les chargements de données en masse, le nombre de points de contrôle requis peut être réduit.
Réponse associée avec plus de détails:
Postgres 9.5
La nouvelle version à venir a une approche plus intelligente. Citant les notes de version bêta :
Remplacer le paramètre de configuration checkpoint_segmentspar min_wal_size
et max_wal_size(Heikki Linnakangas)
Cela permet d'allouer un grand nombre de fichiers WAL sans les conserver s'ils ne sont pas nécessaires. Ainsi, la valeur par défaut de max_wal_size
a été augmentée à 1GB.
A part: le nombre de vues est à peine pertinent, celles-ci ne contiennent aucune donnée, juste la "recette", c'est-à-dire: la requête et certains attributs de la vue. Pour la question posée, seule la taille totale du fichier de sauvegarde importe.
