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

Précédent | Niveau supérieur | Suivant
CLOSE | Sommaire | COMMENT

## CLUSTER

CLUSTER — Réorganiser une table en fonction d'un index

## Synopsis

    CLUSTER [VERBOSE] nom_table [ USING nom_index ]
    CLUSTER ( option [, ...] ) nom_table [ USING nom_index ]
    CLUSTER [VERBOSE]

    où option peut faire partie de :

        VERBOSE [ boolean ]

## Description

`CLUSTER` réorganise (groupe) la table `nom_table` en fonction de l'index `nom_index`. L'index doit avoir été préalablement défini sur `nom_table`.

Une table réorganisée est physiquement réordonnée en fonction des informations de l'index. Ce regroupement est une opération ponctuelle : les actualisations ultérieures ne sont pas réorganisées. C'est-à-dire qu'aucune tentative n'est réalisée pour stocker les lignes nouvelles ou actualisées d'après l'ordre de l'index. (Une réorganisation périodique peut être obtenue en relançant la commande aussi souvent que souhaité. De plus, configurer le paramètre `FILLFACTOR` à moins de 100% peut aider à préserver l'ordre du cluster lors des mises à jour car les lignes mises à jour sont conservées dans la même page si suffisamment d'espace est disponible ici.)

Quand une table est réorganisée, PostgreSQL enregistre l'index utilisé à cet effet. La forme `CLUSTER `nom_table`` réorganise la table en utilisant le même index qu'auparavant. Vous pouvez aussi utiliser les formes `CLUSTER` ou `SET WITHOUT CLUSTER` de `ALTER TABLE` pour initialiser l'index de façon à ce qu'il soit intégré aux prochaines opérations cluster ou pour supprimer tout précédent paramètre.

`CLUSTER`, sans paramètre, réorganise toutes les tables de la base de données courante qui ont déjà été réorganisées et dont l'utilisateur est propriétaire, ou toutes les tables s'il s'agit d'un super-utilisateur. Cette forme de `CLUSTER` ne peut pas être exécutée à l'intérieur d'une transaction.

Quand une table est en cours de réorganisation, un verrou `ACCESS EXCLUSIVE` est acquis. Cela empêche toute opération sur la table (à la fois en lecture et en écriture) pendant l'exécution de `CLUSTER`.

## Paramètres

`nom_table`

  Le nom d'une table (éventuellement qualifié du nom du schéma).

`nom_index`

  Le nom d'un index.

`VERBOSE`

  Affiche la progression pour chaque table traitée.

`boolean`

  Indique si l'option sélectionnée doit être activée ou non. 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é.

## Notes

Lorsque les lignes d'une table sont accédées aléatoirement et unitairement, l'ordre réel des données dans la table n'a que peu d'importance. Toutefois, si certaines données sont plus accédées que d'autres, et qu'un index les regroupe, l'utilisation de `CLUSTER` peut s'avérer bénéfique. Si une requête porte sur un ensemble de valeurs indexées ou sur une seule valeur pour laquelle plusieurs lignes de la table correspondent, `CLUSTER` est utile. En effet, lorsque l'index identifie la page de la table pour la première ligne correspondante, toutes les autres lignes correspondantes sont déjà probablement sur la même page de table, ce qui diminue les accès disque et accélère la requête.

`CLUSTER` peut trier de nouveau en utilisant soit un parcours de l'index spécifié soit (si l'index est un Btree) un parcours séquentiel suivi d'un tri. Il choisira la méthode qui lui semble la plus rapide, en se basant sur les paramètres de coût du planificateur et sur les statistiques disponibles.

Quand un parcours d'index est utilisé, une copie temporaire de la table est créée. Elle contient les données de la table dans l'ordre de l'index. Des copies temporaires de chaque index sur la table sont aussi créées. Du coup, vous devez disposer d'un espace libre sur le disque d'une taille au moins égale à la somme de la taille de la table et des index.

Quand un parcours séquentiel suivi d'un tri est utilisé, un fichier de tri temporaire est aussi créé. Donc l'espace temporaire requis correspond à au maximum le double de la taille de la table et des index. Cette méthode est généralement plus rapide que le parcours d'index mais si le besoin en espace disque est trop important, vous pouvez désactiver ce choix en désactivant temporairement enable_sort (`off`).

Il est conseillé de configurer maintenance_work_mem à une valeur suffisamment large (mais pas plus importante que la quantité de mémoire que vous pouvez dédier à l'opération `CLUSTER`) avant de lancer la commande.

Puisque le planificateur enregistre les statistiques d'ordonnancement des tables, il est conseillé de lancer `ANALYZE` sur la table nouvellement réorganisée. Dans le cas contraire, les plans de requêtes peuvent être mal choisis par le planificateur.

Comme `CLUSTER` se rappelle les index utilisés pour cette opération, un utilisateur peut exécuter manuellement des commandes `CLUSTER` une première fois, puis configurer un script de maintenance périodique qui n'exécutera qu'un `CLUSTER` sans paramètres, pour que les tables soient fréquemment triées physiquement.

Chaque processus exécutant `CLUSTER` indiquera sa progression dans la vue `pg_stat_progress_cluster`. Voir Section 28.4.4 pour les détails.

## Exemples

Réorganiser la table `employes` sur la base de son index `employes_ind` :

    CLUSTER employes ON employes_ind;

Réorganiser la relation `employes` en utilisant le même index que précédemment :

    CLUSTER employes;

Réorganiser toutes les tables de la base de données qui ont déjà été préalablement réorganisées :

    CLUSTER;

## Compatibilité

Il n'existe pas d'instruction `CLUSTER` dans le standard SQL.

La syntaxe

    CLUSTER nom_index ON nom_table

est aussi supportée pour la compatibilité avec les versions de PostgreSQL antérieures à la 8.3.

## Voir aussi

clusterdb, Section 28.4.4