PREPARE TRANSACTION
REINDEX { INDEX | TABLE | DATABASE | SYSTEM } nom [ FORCE ]
REINDEX reconstruit un index en utilisant les données stockées dans la table, remplaçant l'ancienne copie de l'index. Il y a deux raisons principales pour utiliser REINDEX :
Un index a été corrompu et ne contient plus de données valides. Bien qu'en théorie, ceci ne devrait jamais arriver, en pratique, les index peuvent se corrompre à cause de bogues dans le logiciel ou d'échecs matériels. REINDEX fournit une méthode de récupération.
L'index en question contient beaucoup de pages d'index mortes qui ne sont pas réclamées. Ceci peut arriver avec des index B-tree dans PostgreSQL™ sous certains modèles d'accès. 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 22.2, « Ré-indexation régulière » pour plus d'informations.
Recrée l'index spécifié.
Recrée tous les index de la table spécifiée. Si la table a une seconde table « TOAST », elle est aussi réindexée.
Recrée tous les index de la base de données en cours. Les index sur les catalogues système partagés ne sont pas pris en compte sauf dans le mode autonome (voir ci-dessous).
Recrée tous les index des catalogues système à l'intérieur de la base de données en cours. Les index des tables utilisateur ne sont pas traités. De plus, les index sur les catalogues système partagés ne sont pas pris compte sauf dans le mode autonome (voir ci-dessous).
Le nom de l'index, de la table ou de la base de données spécifique à réindexer. Les noms de table et d'index peuvent être qualifiés du nom du schéma. Actuellement, REINDEX DATABASE et REINDEX SYSTEM ne peuvent réindexer que la base de données en cours, donc ce paramètre doit correspondre au nom de la base de données en cours.
Ceci est une option obsolète ; elle est ignorée si elle est spécifiée.
Si vous suspectez une corruption d'un index sur une table utilisateur, vous pouvez simplement reconstruire cet index, ou tous les index de la table, en utilisant REINDEX INDEX ou REINDEX TABLE.
Les choses sont plus difficiles si vous avez besoin de récupérer de la corruption d'un index sur une table système. Dans ce cas, il est important pour le système de ne pas avoir utilisé lui-même un des index suspects. (En fait, dans ce type de scénario, vous pourriez trouver que les processus serveur s'arrêtent brutalement immédiatement au lancement, à cause du besoin des index corrompus.) Pour récupérer proprement, le serveur doit être lancé avec l'option -P, qui l'empêche d'utiliser les index pour les recherches dans les catalogues système.
Une façon de faire ceci est d'arrêter le postmaster et de lancer le serveur PostgreSQL™ en mode autonome avec l'option -P placée sur la ligne de commande. Ensuite, REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE ou REINDEX INDEX peuvent être lancés suivant ce que vous souhaitez reconstruire. En cas de doute, utilisez REINDEX SYSTEM pour sélectionner la reconstruction de tous les index système dans la base de données. Enfin, quittez la session autonome du serveur et relancez le serveur habituel. Voir la page de référence de postgres(1) pour plus d'informations sur l'interaction avec l'interface du serveur autonome.
Une session standard du serveur peut aussi être lancée avec -P dans les options de la ligne de commande. La méthode pour ce faire varie entre les clients mais dans tous les clients basés sur libpq, il est possible de configurer la variable d'environnement PGOPTIONS à -P avant de lancer le client. Notez que, bien que cette méthode ne verrouille pas les autres clients, il est conseillé d'empêcher les autres utilisateurs de se connecter à la base de données endommagée jusqu'à la fin des réparations.
Si une corruption est suspectée dans les index d'un des catalogues système partagés (qui sont pg_authid, pg_auth_members, pg_database, pg_pltemplate, pg_shdepend et pg_tablespace), alors un serveur autonome doit être utilisé pour le réparer. REINDEX ne traite pas les catalogues partagés dans le mode multiutilisateur.
Pour tous les index sauf les catalogues système partagés, REINDEX est protégé contre les arrêts brutaux et utilise les transactions. REINDEX n'est pas protégé pour les index partagés, ce qui explique pourquoi ce cas est désactivé pendant les opérations normales. Si un échec survient lors de la réindexation d'un de ces catalogues dans le mode autonome, il n'est pas possible de relancer le serveur en mode normal jusqu'à ce que le problème soit rectifié (le symptôme typique d'un index partagé reconstruit partiellement est une erreur « index n'est pas un btree »).
REINDEX est similaire à une suppression et à une nouvelle création de l'index dans le fait que le contenu de l'index est complètement recréé. Néanmoins, les considérations de verrouillage sont assez différentes. REINDEX verrouille les écritures mais pas les lectures de la table mère de l'index. Il prend aussi un verrou exclusif sur l'index en cours de traitement, ce qui bloque les lectures qui tentent d'utiliser l'index. Au contraire, DROP INDEX crée temporairement un verrou exclusif sur la table parent, bloquant ainsi écritures et lectures. Le CREATE INDEX qui suit verrouille les écritures mais pas les lectures ; comme l'index n'existe pas, aucune lecture ne peut être tentée, signifiant qu'il n'y a aucun blocage et que les lectures sont probablement forcées de réaliser des parcours séquentiels complets. Un autre point important est que l'approche suppression/création invalide tous plans de requête en cache utilisant cet index, problème que REINDEX ne connaît pas.
Ré-indexer un seul index ou une seule table requiert d'être le propriétaire de cet index ou de cette table. Ré-indexer une base de données requiert d'être le propriétaire de la base de donénes (notez du coup que le propriétaire peut reconstruire les index de tables possédées par d'autres utilisateurs). Bien sûr, les superutilisateurs peuvent toujours tout ré-indexer.
Avant PostgreSQL™ 8.1, REINDEX DATABASE traitait seulement les index systèmes, pas tous les index comme on pourrait le supposer d'après le nom. Ceci a été modifié pour réduire le facteur de surprise. L'ancien comportement est disponible en tant que REINDEX SYSTEM.
Avant PostgreSQL™ 7.4, REINDEX TABLE ne traitait pas automatiquement les tables TOAST et, du coup, elles devaient être réindexées par des commandes séparées. C'est toujours possible mais redondant.
Recrée les index sur la table ma_table :
REINDEX TABLE ma_table;
Reconstruit un index simple :
REINDEX INDEX my_index;
Reconstruit tous les index d'une base de données particulière sans faire confiance à la validité des index système :
$ export PGOPTIONS="-P" $ psql broken_db ... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q