PostgreSQLLa base de données la plus sophistiquée au monde.

CLUSTER

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

Synopsis

CLUSTER [VERBOSE] nom_table [ USING nom_index ]
CLUSTER [VERBOSE]

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 reorganisé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(7) pour initialiser l'index de façon à ce qu'il soit intégré aux prochaines opérations cluster our 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 superutilisateur. 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.

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.

Lors de l'opération de réorganisation, une copie temporaire de la table est créée qui contient les données de la table dans l'ordre de l'index. Des copies temporaires de chaque index de la table sont également créées. De ce fait, il est nécessaire de disposer d'un espace libre sur le disque au moins égal à la somme de la taille de la table et celles des index.

Puisque CLUSTER enregistre les informations de réorganisation, il est possible de réorganiser manuellement les tables souhaitées la première fois et de planifier une réorganisation, à la manière de VACUUM, pour que les tables soient régulièrement réorganisées.

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

Il existe une autre façon de réorganiser les données. La commande CLUSTER réorganise la table originale en la parcourant en fonction de l'ordre de l'index indiqué ; cela peut être lent pour les tables volumineuses parce que les lignes sont extraites de la table dans l'ordre de l'index et, si la table n'est pas ordonnée, les entrées sont disséminées sur des pages aléatoires. Une page disque est alors lue pour chaque ligne déplacée. (PostgreSQL™ dispose d'un cache mais une grande table n'y tient généralement pas dans sa totalité.) L'autre moyen de réorganiser une table est alors d'utiliser :

CREATE TABLE nouvelletable AS
    SELECT * FROM table ORDER BY listecolonnes;

qui utilise le code de tri de PostgreSQL™ pour aboutir à l'ordre désiré ; pour des données non triées, cela est généralement bien plus rapide qu'un parcours d'index. L'ancienne table peut alors être supprimée et nouvelletable renommée en table à l'aide de ALTER TABLE ... RENAME. Il ne reste plus qu'à recréer les index de la table. Le gros inconvénient de cette approche est qu'elle ne préserve pas les OID, les contraintes, les relations de clés étrangères, les droits et autres propriétés de la table -- tous ces éléments doivent être recréés manuellement. Un autre inconvénient est la nécessité d'un fichier temporaire de tri de la même taille que la table elle-même. Le pic d'utilisation du disque est alors d'environ trois fois la taille de la table au lieu de deux fois.

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(1)