Un REINDEX est-il nécessaire après CLUSTER?

J'envisage d'utiliser CLUSTER pour réorganiser une table par un index. Je comprends que cette recréation des données de la table rend tous les index existants gonflés ou inutiles. J'ai vu quelques indications qu'un REINDEX est requis après un CLUSTER. J'ai trouvé d'autres références qui indiquent que CLUSTER fait un REINDEX. La documentation officielle ne dit rien du tout sur REINDEX faisant partie de CLUSTER ou requis (bien qu'elle suggère d'exécuter ANALYZE après le CLUSTER)

Quelqu'un peut-il définitivement (c'est-à-dire avec une sorte de référence aux documents officiels) dire si oui ou non un REINDEX est requis après un CLUSTER?

Vous n'avez pas besoin de réindexer, car CLUSTERil le fait efficacement pour vous.

Plus précisément, CLUSTERverrouille la table source puis en crée une nouvelle copie ordonnée en fonction de l'index cible. Il crée des index sur la nouvelle copie, puis remplace l'ancienne table et les index par les nouveaux.

Notez que cela est également vrai VACUUM FULLdans la version 9.0+.

Si vous avez vu une discussion suggérant que les CLUSTERindex gonflés peuvent être des gens qui supposent que cela CLUSTERfonctionne comme avant la version 9.0 VACUUM FULL. Vous pouvez également voir et mal interpréter des discussions qui mentionnent le gonflement d'index causé par l'ancienne VACUUM FULLimplémentation et suggèrent CLUSTERune alternative .

Ceci est impliqué dans la documentation :

une copie temporaire de la table est créée qui contient les données de la table dans l'ordre d'index. Des copies temporaires de chaque index de la table sont également créées . Par conséquent, vous avez besoin d'espace libre sur le disque au moins égal à la somme de la taille de la table et des tailles d'index

Ce qu'il ne dit pas, mais devrait, c'est que ces copies temporaires remplacent alors la table d'origine . (Mine audacieuse).

Je suis avec a_horse_with_no_name à ce sujet: vous n'avez pas besoin de recréer les index. Outre que la CLUSTERdocumentation ne le mentionne pas, nous pouvons également consulter la REINDEXpage:

Il existe plusieurs scénarios dans lesquels utiliser REINDEX:

• Un index est corrompu et ne contient plus de données valides. Bien qu'en théorie cela ne devrait jamais se produire, dans la pratique, les index peuvent être corrompus en raison de bogues logiciels ou de pannes matérielles. REINDEX fournit une méthode de récupération.

• Un index est devenu "gonflé", c'est-à-dire qu'il contient de nombreuses pages vides ou presque vides. Cela peut se produire avec des index B-tree dans PostgreSQL sous certains modèles d'accès rares. REINDEX fournit un moyen de réduire la consommation d'espace de l'index en écrivant une nouvelle version de l'index sans les pages mortes. Voir Section 23.2 pour plus d'informations.

• Vous avez modifié un paramètre de stockage (tel que fillfactor) pour un index et souhaitez vous assurer que la modification a pris pleinement effet.

• Une génération d'index avec l'option CONCURRENTLY a échoué, laissant un index "non valide". De tels index sont inutiles mais il peut être pratique d'utiliser REINDEX pour les reconstruire. Notez que REINDEX n'effectuera pas de génération simultanée. Pour créer l'index sans interférer avec la production, vous devez supprimer l'index et relancer la commande CREATE INDEX CONCURRENTLY.

De toute évidence, CLUSTERne tombe dans aucun de ces cas.

Et il y a une petite phrase dans les CLUSTERdocuments:

[lors du clustering] Des copies temporaires de chaque index de la table sont également créées.

Cela suggère que, tout comme la table elle-même, les index sont également réorganisés au cours du processus, ce qui rend la réindexation inutile.

Trouvé une référence, dans la section Récupération de l'espace disque .

Si vous avez une telle table et que vous devez récupérer l'espace disque excédentaire qu'elle occupe, vous devrez utiliser VACUUM FULL, ou alternativement CLUSTER ou l'une des variantes de réécriture de table d'ALTER TABLE. Ces commandes réécrivent une nouvelle copie entière de la table et créent de nouveaux index pour elle.

En analysant toutes les réponses, à mon avis, la bonne façon de le faire est de réindexer AVANT le cluster. Comme la documentation ne dit pas si le cluster fait ou non une réindexation, et seulement une copie de l'index, ordonné ou non, je pense qu'un index indexé se traduira par une meilleure table en cluster. Après cela, une analyse terminera le travail. Un vide plein avant tout semble inutile, à moins que le cluster et / ou la réindexation ne libèrent pas de tuples morts