CLUSTER
CLUSTER — Réorganiser une table en fonction d'un index
Synopsis
CLUSTER nomindex ON nomtable
CLUSTER nomtable
CLUSTER
Description
CLUSTER
réorganise
(groupe) la table
nomtable
en
fonction de l'index
nomindex
.
L'index doit avoir été préalablement défini sur
nomtable
.
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é.
Quand une table est réorganisée, PostgreSQL™ enregistre l'index utilisé à
cet effet. La forme
CLUSTER
nomtable
réorganise la table d'après l'index précédemment utilisé.
CLUSTER
, sans
paramètre, réorganise toutes les tables de la base de données
courante dont l'utilisateur est propriétaire, ou toutes les tables
s'il s'agit d'un superutilisateur. (Les tables qui n'ont jamais été
réorganisées sont ignorées.) 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
-
nomindex
-
Le nom d'un index.
-
nomtable
-
Le nom d'une table (éventuellement qualifié du nom du
schéma).
Notes
CLUSTER
supprime
toute information de visibilité des lignes, ce qui donne
l'impression, à tout instantané de la base pris avant la fin de la
commande
CLUSTER
, que
la table est vide.
CLUSTER
est de ce fait
incompatible avec les applications dont certaines transactions
accèdent concurrentiellement à la table en cours de réorganisation
(clusterisation). L'impact est encore plus important avec les
transactions sérialisables car elles ne prennent un instantané de
la base qu'au début de la transaction. Cela dit, les transactions «
read-committed » sont aussi affectées.
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 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 emp_ind :
CLUSTER emp_ind ON employes;
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.