CLUSTER — Réorganiser une table en fonction d'un index
CLUSTER [VERBOSE]nom_table
[ USINGnom_index
] CLUSTER (option
[, ...] )nom_table
[ USINGnom_index
] CLUSTER [VERBOSE] oùoption
peut faire partie de : VERBOSE [boolean
]
CLUSTER
réorganise (trie) 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 triée en fonction des informations de
l'index. Ce tri est une opération ponctuelle : les actualisations
ultérieures ne sont pas triées. C'est-à-dire qu'aucune tentative n'est
réalisée pour stocker les nouvelles lignes ou les lignes mises à jour 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 tri 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
réorganise
la table en utilisant le même index que la dernière fois. Vous pouvez aussi
utiliser les formes nom_table
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
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
.
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é.
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. De ce fait, 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 l'optimiseur 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 l'optimiseur.
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.
Exécuter la commande CLUSTER
sur une table partitionnée va
exécuter CLUSTER
sur chacune de ses partitions en
utilisant la partition de l'index partitionné indiqué. Dans ce cas, l'index
ne peut pas être omis.
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;
Il n'existe pas d'instruction CLUSTER
dans le standard
SQL.
La syntaxe
CLUSTERnom_index
ONnom_table
est aussi supportée pour la compatibilité avec les versions de PostgreSQL antérieures à la 8.3.