Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
étant donné que le temps mis pour lancer la commande "vacuum full" est prohibitif sur des tables volumineuses, je me posais une question :
au lieu de faire un vacuum full, est-ce équivalent de faire un pg_dump des données de la table, puis un truncate de la table en question, puis un pg_restore de la même table depuis le fichier créé?
Puisque la table est vide, je suppose que les index sont recréés en faisant le pg_restore?
Merci pour vos avis
Hors ligne
Pourquoi faire un vacuum full au lieu d'un vacuum ?
Sinon, déjà, pour faire un truncate de la table puis un réimport des données, il faut qu'aucun utilisateur n'utilise la table à ce moment-là...
Hors ligne
1 - parce que le vacuum full est me semble-t-il plus efficace pour gagner de la place
2 - faire un vacuum full bloque de toute façon la base ;
3 - si je la mets en maintenance la nuit, j'éviterai que des utilisateurs n'y accèdent à ce moment-là (enfin c'est pas garanti de toute façon surtout s'ils ont des scripts qui tournent)
Hors ligne
Le VACUUM FULL va bloquer la table en cours de traitement. Cela étant dit, il est préférable de faire des VACUUM. Le gros du travail est d'avoir suffisamment de VACUUM pour ne pas avoir besoin de VACUUM FULL tout en n'en faisant pas trop pour ne pas surcharger le serveur.
L'expérience montre qu'il est souvent difficile de trouver le bon moment pour faire un VACUUM FULL. Et que ce moment peut changer. Il est déjà arrivé à un client que le VACUUM FULL se fasse bien une année durant et qu'un jour le VACUUM FULL était toujours actif le matin à cause d'une activité importante la veille. Résultat des courses : tout le monde bloqué le matin.
Bref tout ça pour dire : faites le maximum pour éviter d'utiliser VACUUM FULL.
Guillaume.
Hors ligne
Et sans compter qu'un VACUUM FULL pourri les index 
Thomas Reiss
Hors ligne
Sauf en 9.0 
Guillaume.
Hors ligne
Pages : 1
