Documentation PostgreSQL 14.22 » Référence » Commandes SQL » VACUUM

Précédent | Niveau supérieur | Suivant
UPDATE | Sommaire | VALUES

## VACUUM

VACUUM — récupère l'espace inutilisé et, optionnellement, analyse une base

## Synopsis

    VACUUM [ ( option [, ...] ) ] [ table_et_colonnes [, ...] ]
    VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ table_et_colonnes [, ...] ]

    où option fait partie de :

        FULL [ boolean ]
        FREEZE [ boolean ]
        VERBOSE [ boolean ]
        ANALYZE [ boolean ]
        DISABLE_PAGE_SKIPPING [ boolean ]
        SKIP_LOCKED [ boolean ]
        INDEX_CLEANUP [ AUTO | ON | OFF ]
        PROCESS_TOAST [ boolean ]
        TRUNCATE [ boolean ]
        PARALLEL integer

    et table_et_colonnes est :

        nom_table [ ( nom_colonne [, ...] ) ]

## Description

`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 la description d'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. Elle nous permet aussi d'exploiter plusieurs CPU pour traiter les index. Cette fonctionnalité est connue sous le nom vacuum parallélisé. Pour désactiver cette fonctionnalité, l'option `PARALLEL` peut être utilisée en spécifiant le nombre de workers à zéro. `VACUUM FULL` réécrit le contenu entier d'une table dans un nouveau fichier sur disque sans espace supplémentaire, permettant ainsi à l'espace non utilisé d'être retourné au système d'exploitation. Cette forme est bien plus lente et requiert un verrou de type `ACCESS EXCLUSIVE` sur chaque table pendant qu'elle s'exécute.

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.

## 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. 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 agressif est toujours effectué quand la table est réécrite, cette option est donc redondante quand `FULL` est spécifié.

`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.

`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`

  Habituellement, `VACUUM` ignorera le traitement des index quand il y a très peu de lignes mortes dans la table. Quand cela arrive, le coût de traitement de tous les index de la table devrait dépasser fortement l'intérêt de supprimer les lignes mortes de l'index. Cette option peut être utilisée pour forcer un `VACUUM` à traiter les index quand il y a plus de zéro ligne morte. La valeur par défaut est `AUTO`, ce qui permet au `VACUUM` d'ignorer le traitement des index quand il estime que c'est approprié. Si `INDEX_CLEANUP` est configuré à `ON`, `VACUUM` supprimera de façon conservatrice toutes les lignes mortes des index. Ceci pourrait être utile pour une compatibilité descendante avec les anciennes versions de PostgreSQL pour lesquelles ceci était le comportement par défaut.

  `INDEX_CLEANUP` peut aussi être configuré à `OFF` pour forcer `VACUUM` à toujours ignorer le traitement des index, même s'il y a un grand nombre de lignes mortes dans la table. Ceci pourrait être utile quand il est nécessaire que `VACUUM` termine aussi rapidement que possible pour éviter une réutilisation des identifiants de transaction(voir Section 25.1.5). Néanmoins, le mécanisme de sécurité du wraparound contrôlé par vacuum_failsafe_age se déclenchera automatiquement pour éviter un échec de la réutilisation des identifiants. Si le nettoyage des index n'est pas réalisé régulièrement, les performances pourraient en souffrir car, comme la table est modifiée, les index accumuleraient des lignes mortes et la table elle-même accumulerait des pointeurs des pointeurs de lignes mortes qui ne peuvent être supprimés jusqu'au nettoyage de l'index.

  Cette option n'a pas d'effet pour les tables qui n'ont pasd'index et est ignoré si l'option `FULL` est utilisée. Elle n'a aussi aucun effet sur le mécanisme de sécurité sur la réutilisation ds identifiants de transactions. Lorsqu'elle est déclenchée, le traitement des indexsera ignoré même si `INDEX_CLEANUP` est configuré à `ON`.

`PROCESS_TOAST`

  Indique que `VACUUM` doit tenter de traiter la table `TOAST` correspondante pour chaque relation, si cette table existe. Ceci est normalement le comportement désiré et c'est de ce fait le comportement par défaut. Configurer cette option à false peut être utile quand il est seulement nécessaire de traiter la table principale. Cette option est requise quand 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.

`PARALLEL`

  Effectue les phases de vacuum et de nettoyage d'index lors d'un `VACUUM` en parallèle en utilisant `integer` processus en tâche de fond (pour les détails de chaque phase de vacuum, référez-vous au Tableau 28.39). Le nombre de workers utilisés pour réaliser l'opération est égal au nombre d'index sur la relation qui supporte le vacuum parallélisé, qui est limité par le nombre de workers spécifiés avec la clause `PARALLEL` qui est elle-même limitée par le paramètre max_parallel_maintenance_workers. Un index peut participer à un vacuum parallélisé si et seulement si la taille de l'index est supérieur à la valeur du paramètre min_parallel_index_scan_size. Notez qu'il n'est pas garanti que le nombre de workers parallélisés indiqué dans `integer` sera utilisé lors de l'exécution. Il est possible qu'un vacuum s'exécute avec moins de workers que spécifié, voire sans workers du tout. Seul un worker peut être utilisé par index. Donc les workers de parallélisation sont lancés seulement quand il y a au moins `2` index dans la table. Les workers pour le vacuum sont lancés avant le début de chaque phase et se terminent à la fin de la phase. Ces comportements pourraient changer dans une version future. Cette option ne peut pas être utilisée avec l'option `FULL`.

`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é.

`integer`

  Spécifie une valeur entière non négative passée à l'option sélectionnée.

`nom_table`

  Le 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.

## 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

Pour exécuter un VACUUM sur une table, vous devez habituellement être le propriétaire de la table ou un super-utilisateur. 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 super-utilisateur.) `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 la Section 67.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`.

L'option `PARALLEL` est utilisée seulement pour le vacuum. Si cette option est spécifiée avec l'option `ANALYZE`, elle n'affecte pas `ANALYZE`.

`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. Pour un vacuum en parallèle, chaque processus dort proportionnellement au travail effectué par ce processus. Voir la Section 20.4.4 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 la Section 25.1.

Chaque processus exécutant `VACUUM` sans l'option `FULL` indiquera sa progression dans la vue `pg_stat_progress_vacuum`. Les processus exécutant `VACUUM FULL` indiqueront leur progression dans la vue `pg_stat_progress_cluster`. Voir Section 28.4.3 et Section 28.4.4 pour les détails.

## Exemples

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;

## Compatibilité

Il n'y a pas de commande `VACUUM` dans le standard SQL.

## Voir aussi

vacuumdb, Section 20.4.4, Section 25.1.6, Section 28.4.3, Section 28.4.4