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.

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

Affiche un rapport détaillé de l'activité de vacuum sur chaque table.

Met à jour les statistiques utilisées par l'optimiseur pour déterminer la méthode la plus efficace pour exécuter une requête.

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.

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.

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.

Indique que la commande VACUUM doit tenter de traiter la relation principale. Ceci est habituellement le comportement souhaité se trouve donc être le comportement par défaut. Configurer cette option à false pourrait être utile quand il est nécessaire de traiter la table TOAST correspondante de cette relation.

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.

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.

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.45). 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.

Indique que VACUUM doit ignorer la mise à jour des statistiques sur la base à propos des identifiants de transactions non gelés les plus anciens. Normalement, VACUUM met à jour ces statistiques une fois arrivé à la fin de la commande. Néanmoins, ceci peut prendre du temps sur une base de données avec un grand nombre de tables, et cela n'accomplirait rien sauf si la table qui contient l'identifiant de transaction non gelé le plus ancien fait partie des tables traitées. De plus, si plusieurs commandes VACUUM sont exécutées en parallèle, seule une d'entre elles à la fois peut mettre à jour les statistiques. De ce fait, si une application doit lancer plusieurs commandes VACUUM, il peut être utile de configurer cette option dans toutes les commandes sauf la dernière ou de la configurer dans toutes les commandes, puis de lancer séparément une commande VACUUM (ONLY_DATABASE_STATS) à la fin.

Indique que VACUUM ne devrait rien faire à part mettre à jour les statistiques sur la base à propos des identifiants de transaction non gelés les plus anciens. Quand cette option est indiqué, la liste table_et_colonnes doit être vide et aucune autre option ne doit être activée, à l'exception de VERBOSE.

Indique la taille du buffer de la commande VACUUM dans le contexte du Buffer Access Strategy. Cette taille est utilisé pour calculer le nombre de blocs du cache disque de PostgreSQL qui seront ré-utilisés dans le cadre de cette stratégie. 0 désactive l'utilisation du Buffer Access Strategy. Si ANALYZE est aussi indiquée, la valeur de BUFFER_USAGE_LIMIT est utilisé pour les deux opérations : nettoyage et calcul des statistiques. Cette option ne peut pas être utilisée avec l'option FULL sauf si ANALYZE est aussi indiqué. Quand cette option n'est pas indiquée, VACUUM utilise la valeur provenant du paramètre vacuum_buffer_usage_limit. Des valeurs hautes peuvent permettre à VACUUM de s'exécuter plus rapidement, mais une valeur trop haute peut causer l'éviction du cache d'un trop grand nombre de blocs utiles. La valeur minimale est 128 kB et la valeur maximale est 16 GB.

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

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

Indique une quantité de mémoire en kilooctets. Les tailles peuvent aussi être indiquées comme une chaîne contenant la taille numérique suivie d'une unité parmi :: B (octets), kB (kilo-octets), MB (mega-octets), GB (giga-octets) ou TB (tera-octets).

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.

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.