Description

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 plusieurs raisons pour utiliser REINDEX :

Paramètres

Notes

Si vous suspectez la 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 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 constater que les processus serveur s'arrêtent brutalement au lancement du service, mettant en cause l'utilisation des index corrompus.) Pour récupérer proprement, le serveur doit être lancé avec l'option -P, qui inhibe l'utilisation des index pour les recherches dans les catalogues système.

Une autre façon est d'arrêter le serveur et de relancer le serveur PostgreSQL en mode simple utilisateur 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 la commande REINDEX SYSTEM pour activer la reconstruction de tous les index système de la base de données. Enfin, quittez la session simple utilisateur du serveur et relancez le serveur en mode normal. Voir la page de référence de postgres pour plus d'informations sur l'interaction avec l'interface du serveur en mode simple utilisateur.

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.

REINDEX est similaire à une suppression et à une nouvelle création de l'index. Dans les faits, 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 positionne également un verrou de type ACCESS EXCLUSIVE sur l'index en cours de traitement, ce qui bloque les lectures qui tentent de l'utiliser. En particulier, l'optimiseur de requêtes essaie de prendre un verrou ACCESS SHARE sur chaque index de la table, quelque soit la requête, et de ce fait, REINDEX bloque virtuellement toute requête sauf certaines requêtes préparées dont le plan a été mis en cache et qui n'utilise pas cet index. Au contraire, DROP INDEX prends temporairement un verrou de type ACCESS EXCLUSIVE 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.

Ré-indexer un seul index ou une seule table requiert d'être le propriétaire de cet index ou de cette table. Ré-indexer un schéma ou une base de données requiert d'être le propriétaire du schéma ou de la base de données. Notez que, du coup, il est parfois possible pour des utilisateurs standards de reconstruire les index de tables dont ils ne sont pas propriétaires Néanmoins, il existe une exception spéciale, quand la commande REINDEX DATABASE, REINDEX SCHEMA ou REINDEX SYSTEM est exécutée par un utilisateur standard, les index sur les catalogues partagés seront ignorés sauf si l'utilisateur possède le catalogue (ce qui ne sera généralement pas le cas). Bien sûr, les superutilisateurs peuvent toujours tout ré-indexer.

Réindexer des index partitionnés ou des tables partitionnées est supporté avec les commandes respectives REINDEX INDEX et REINDEX TABLE. Chaque partition de la relation partitionnée est réindexée dans une transaction séparée. Ces commandes ne peuvent pas être utilisées à l'intérieur d'un bloc de transaction lors d'un travail sur une table partitionnée ou sur un index partitionnée.

Lors de l'utilisation de la clause TABLESPACE avec REINDEX sur une table ou un index partitionné, seules les références du tablespace des partitions feuilles sont mises à jour. Comme les index partitionnées ne sont pas mis à jour, il est recommandé d'utiliser séparément ALTER TABLE ONLY sur celles-ci pour que toute nouvelle partition attachée hérite du nouveau tablespace. En cas d'échec, il pourrait ne pas avoir déplacer tous les index vers le nouveau tablespace. Ré-exécuter la commande reconstruira les partitions feuilles et déplacera les index non traités précédemment vers le nouveau tablespace.

Si SCHEMA, DATABASE ou SYSTEM sont utilisés avec TABLESPACE, les relations systèmes sont ignorés et un simple message WARNING sera généré. Les index sur les tables TOAST sont reconstruits, mais pas déplacés dans le nouveau tablespace.

postgres=# \d tab
       Table "public.tab"
 Column |  Type   | Modifiers
--------+---------+-----------
 col    | integer |
Indexes:
    "idx" btree (col)
    "idx_ccnew" btree (col) INVALID
    

Exemples

Reconstruit un index simple :

REINDEX INDEX my_index;
   

Recrée les index sur la table ma_table :

REINDEX TABLE ma_table;
   

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
   

Reconstruit les index d'une table tout en ne bloquant pas les opérations de lectures et d'écriture sur les relations impliquées lors de la réindexation :

REINDEX TABLE CONCURRENTLY my_broken_table;
   

Compatibilité

Il n'existe pas de commande REINDEX dans le standard SQL.

Voir aussi