VACUUM — récupère l'espace inutilisé et, optionnellement, analyse une base
VACUUM [ (option[, ...] ) ] [table_et_colonnes[, ...] ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [table_et_colonnes[, ...] ] oùoptionfait partie de : FULL [boolean] FREEZE [boolean] VERBOSE [boolean] ANALYZE [boolean] DISABLE_PAGE_SKIPPING [boolean] SKIP_LOCKED [boolean] INDEX_CLEANUP [boolean] TRUNCATE [boolean] ettable_et_colonnesest :nom_table[ (nom_colonne[, ...] ) ]
VACUUM récupère l'espace de stockage occupé par des
lignes mortes.
Lors des opérations normales de PostgreSQL,
les lignes supprimées ou rendues obsolètes par une mise à jour
ne sont pas physiquement supprimées de leur table. Elles restent présentes
jusqu'à ce qu'un VACUUM soit lancé.
C'est pourquoi, il est nécessaire de faire un VACUUM
régulièrement, spécialement sur les tables fréquemment mises à jour.
Sans une liste table_et_colonnes,
VACUUM traite chaque table et vue matérialisée que
l'utilisateur actuel a le droit de traiter ainsi. Avec une liste,
VACUUM ne traite que ces tables.
VACUUM ANALYZE fait un VACUUM,
puis un ANALYZE sur chaque table sélectionnée.
C'est une combinaison pratique pour les scripts de maintenance de
routine. Voir
ANALYZE pour avoir
plus de détails sur ce qu'il traite.
Le VACUUM standard (sans FULL)
récupère simplement l'espace et le rend disponible pour une réutilisation.
Cette forme de la commande peut opérer en parallèle avec les opérations
normales de lecture et d'écriture de la table, car elle n'utilise pas de
verrou exclusif. Néanmoins, l'espace récupéré n'est pas renvoyé au système
de fichiers dans la plupart des cas ; il est conservé pour être
réutilisé dans la même table. VACUUM FULL ré-écrit le
contenu complet de la table dans un nouveau fichier sur disque sans
perte d'espace, permettant à l'espace inutilisé d'être retourné au système
d'exploitation. Cette forme est bien plus lente et nécessite un verrou
de type ACCESS EXCLUSIVE sur chaque table le temps de
son traitement.
Quand la liste d'options est entourée de parenthèses, les options peuvent être écrites dans n'importe quel ordre. Sans parenthèses, les options doivent être écrit dans l'ordre exact décrit ci-dessus. La syntaxe avec parenthèse a été ajoutée dès la version 9.0 de PostgreSQL ; la syntaxe sans parenthèse est maintenant considérée comme obsolète.
FULLChoisit un vacuum « full », qui récupère plus d'espace, mais est beaucoup plus long et prend un verrou exclusif sur la table. Cette méthode requiert aussi un espace disque supplémentaire car il écrit une nouvelle copie de la table et ne supprime l'ancienne copie qu'à la fin de l'opération. Habituellement, cela doit seulement être utilisé quand une quantité importante d'espace doit être récupérée de la table.
FREEZE
Choisit un « gel » agressif des lignes.
Indiquer FREEZE est équivalent à réaliser un
VACUUM avec les paramètres
vacuum_freeze_min_age et
vacuum_freeze_table_age configurés à zéro.
Un gel aggressif est toujours effectué quand la table est
réécrite, cette option est donc redondante quand FULL
est spécifié.
VERBOSEAffiche un rapport détaillé de l'activité de vacuum sur chaque table.
ANALYZEMet à jour les statistiques utilisées par l'optimiseur pour déterminer la méthode la plus efficace pour exécuter une requête.
DISABLE_PAGE_SKIPPING
Habituellement, VACUUM ignorera certains blocs en se
basant sur la carte de
visibilité. Les blocs connues pour être entièrement gelés peuvent
toujours être ignorés, et ceux où toutes les lignes sont connues pour
être visibles par toutes les transactions peuvent être ignorées sauf
lors de l'exécution d'un vacuum agressif. De plus, en dehors d'un vacuum
agressif, certains blocs peuvent être ignorés pour éviter d'attendre la
fin de leur utilisation par d'autres sessions. Cette option désactive
entièrement ce comportement permettant d'ignorer certains blocs, et a
pour but d'être utilisé uniquement quand le contenu de la carte de
visibilité semble suspect, ce qui peut arrive seulement s'il y a un
problème matériel ou logiciel causant une corruption de la base de
données.
SKIP_LOCKED
Indique que VACUUM ne doit pas attendre la
disponibilité d'un verrou en conflit sur une table : si une table
ne peut pas être verrouillée immédiatement sans attente, la table est
ignorée. Notez que, même avec cette option, VACUUM
pourrait toujours être bloqué lors de l'ouverture des index de la table.
De plus, VACUUM ANALYZE pourrait toujours être bloqué
lors de l'accès aux lignes de l'échantillon pour les partitions, les
enfants dans le cadre d'un héritage de tables, et certains types de
tables distantes. De plus, alors que VACUUM traite de
façon standard toutes les partitions des tables partitionnées
spécifiées, cette option fera en sorte que VACUUM
ignorera toutes les partitions s'il y a un verrou en conflit sur la
table partitionnée.
INDEX_CLEANUP
Indique que VACUUM doit tenter de supprimer les
enregistrements de l'index qui pointent vers des lignes mortes. Ceci est
le comportement habituellement désiré et est donc la valeur par défaut
sauf si l'option vacuum_index_cleanup a été
configurée à false pour la table en cours de traitement. Configurer
cette option à false peut être utile quand il est nécessaire de rendre
le VACUUM aussi rapide que possible, par exemple pour éviter une
réutilisation imminente des identifiants de transaction (voir Section 24.1.5). Néanmoins, si le nettoyage de
l'index n'est pas réalisé régulièrement, les performances pourraient en
souffrir parce que, la table étant modifiée, les index accumulent des
lignes mortes et la table elle-même accumule des pointeurs de ligne
mortes qui ne peuvent pas être supprimés tant que le nettoyage de
l'index n'est pas terminé. Cette option n'a aucun effet pour les tables
qui n'ont pas d'index et est ignoré si l'option FULL
est utilisée.
TRUNCATE
Indique que VACUUM doit tenter de tronquer toute page
vide en fin de table et permettre que l'espace disque des pages
tronquées soit rendu au système d'exploitation. Ceci est le comportement
désiré habituellement et est le comportement par défaut sauf si l'option
vacuum_truncate a été désactivée pour la table en
cours de traitement. Configurer cette option à false peut être utile
pour éviter un verrou ACCESS EXCLUSIVE sur la table
que le troncage requiert. Cette option est ignorée si l'option
FULL est utilisée.
boolean
Indique si l'option sélectionnée doit être activée ou désactivée. Vous
pouvez écrire TRUE, ON ou
1 pour activer l'option, et FALSE,
OFF ou 0 pour la désactiver. La
valeur boolean peut aussi
être omise, auquel cas TRUE est supposé.
nom_tableLe nom (optionnellement qualifié par le nom d'un schéma) d'une table ou d'une vue matérialisée à traiter par vacuum. Si la table spécifiée est partitionnée, toutes les partitions enfants seront traitées.
nom_colonne
Le nom d'une colonne spécifique à analyser. Par défaut, toutes les
colonnes. Si une liste de colonnes est spécifiée,
ANALYZE en est déduit.
Lorsque VERBOSE est précisé, VACUUM indique sa
progression par des messages indiquant la table en cours
de traitement. Différentes statistiques sur les tables sont aussi
affichées.
Pour exécuter un VACUUM sur une table, vous devez habituellement être le
propriétaire de la table ou un superutilisateur. Néanmoins, les
propriétaires de la base de données sont autorisés à exécuter VACUUM sur
toutes les tables de leurs bases de données, sauf sur les catalogues
partagés. Cette restriction signifie qu'un vrai VACUUM
sur une base complète ne peut se faire que par un superutilisateur.)
VACUUM ignorera toutes les tables pour lesquelles
l'utilisateur n'a pas le droit d'exécuter un VACUUM.
VACUUM ne peut pas être exécuté à l'intérieur
d'un bloc de transactions.
Pour les tables ayant des index GIN, VACUUM
(sous n'importe quelle forme) termine aussi toutes les insertions d'index en
attente, en déplaçant les entrées d'index aux bons endroits dans la structure
d'index GIN principale. Voir Section 66.4.1
pour les détails.
Nous recommandons que les bases de données actives de production soient
traitées par vacuum fréquemment (au moins toutes les nuits), pour supprimer
les lignes mortes. Après avoir ajouté ou supprimé un grand nombre de
lignes, il peut être utile de faire un VACUUM ANALYZE
sur la table affectée. Cela met les catalogues système à jour
de tous les changements récents et permet à l'optimiseur de
requêtes de PostgreSQL de faire de meilleurs
choix lors de l'optimisation des requêtes.
L'option FULL n'est pas recommandée en usage normal, mais
elle peut être utile dans certains cas. Par exemple, si vous avez supprimé
ou mis à jour l'essentiel des lignes d'une table et si vous voulez que la table diminue
physiquement sur le disque pour n'occuper que l'espace réellement
nécessaire et pour que les parcours de table soient plus rapides.
Généralement, VACUUM FULL réduit plus la table qu'un
simple VACUUM.
VACUUM peut engendrer une
augmentation substantielle du trafic en entrées/sorties pouvant causer
des performances diminuées pour les autres sessions actives. Du coup,
il est quelque fois conseillé d'utiliser la fonctionnalité du délai du
vacuum basé sur le coût. Voir Chapitre 18
pour des informations supplémentaires.
PostgreSQL inclut un « autovacuum » qui peut automatiser la maintenance par VACUUM. Pour plus d'informations sur le VACUUM automatique et manuel, voir Section 24.1.
Pour nettoyer une seule table onek, l'analyser pour
l'optimiseur et afficher un rapport détaillé de l'activité du VACUUM :
VACUUM (VERBOSE, ANALYZE) onek;
Il n'y a pas de commande VACUUM dans le standard SQL.