VACUUM
VACUUM — récupère l'espace inutilisé et, optionnellement,
analyse une base
Synopsis
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (colonne [, ...] ) ] ]
Description
VACUUM
récupère
l'espace de stockage occupé par des lignes supprimées. 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 paramètre,
VACUUM
traite toutes les tables
de la base de données courante. Avec un paramètre,
VACUUM
ne traite que cette table.
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.
VACUUM FULL
fait un traitement plus complet et, en particulier, déplace des
lignes dans d'autres blocs pour compacter la table au maximum sur
le disque. Cette forme est beaucoup plus lente et pose un verrou
exclusif sur la table pour faire son traitement.
Paramètres
-
FULL
-
Choisit un vacuum « full », qui récupère plus d'espace, mais
est beaucoup plus long et prend un verrou exclusif sur la
table.
-
FREEZE
-
Choisit un « gel »
agressif des lignes. Indiquer FREEZE
est équivalent à réaliser un
VACUUM
avec le paramètre
vacuum_freeze_min_age
configuré à zéro. L'option FREEZE
est obsolète et sera supprimée dans une version future ;
configurez ce paramètre à la place.
-
VERBOSE
-
Affiche un rapport détaillé de l'activité de vacuum sur
chaque table.
-
ANALYZE
-
Met à jour les statistiques utilisées par l'optimiseur pour
déterminer la méthode la plus efficace pour exécuter une
requête.
-
table
-
Le nom (optionnellement qualifié par le nom d'un schéma)
d'une table à traiter par vacuum. Par défaut, toutes les
tables de la base de données courante sont traitées.
-
colonne
-
Le nom d'une colonne spécifique à analyser. Par défaut,
toutes les colonnes.
Sorties
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.
Notes
VACUUM
ne peut pas
être exécuté à l'intérieur d'un bloc de transactions.
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 expirées. 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é 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. Généralement,
VACUUM FULL
réduit
plus la table qu'un simple
VACUUM
. L'option FULL ne réduit pas la taille des index ; un
REINDEX
périodique
est toujours recommandé. En fait, il est souvent plus rapide de
supprimer tous les index, d'exécuter un
VACUUM FULL
puis de recréer les
index.
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 Report
du VACUUM en fonction de son coût 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 22.1,
« Nettoyages réguliers ».
Exemples
Ce qui suit est un exemple de lancement de
VACUUM
sur une table de la base
de données regression.
regression=# VACUUM VERBOSE ANALYZE onek;
INFO: vacuuming "public.onek"
INFO: index "onek_unique1" now contains 1000 tuples in 14 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.08u sec elapsed 0.18 sec.
INFO: index "onek_unique2" now contains 1000 tuples in 16 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.07u sec elapsed 0.23 sec.
INFO: index "onek_hundred" now contains 1000 tuples in 13 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.08u sec elapsed 0.17 sec.
INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.09u sec elapsed 0.59 sec.
INFO: "onek": removed 3000 tuples in 108 pages
DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec.
INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages
DETAIL: 0 dead tuples cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.07s/0.39u sec elapsed 1.56 sec.
INFO: analyzing "public.onek"
INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows
VACUUM
Compatibilité
Il n'y a pas de commande
VACUUM
dans le standard SQL.
UPDATE
