Documentation PostgreSQL 9.5.25 > Administration du serveur > Planifier les tâches de maintenance > Ré-indexation régulière | |
Planifier les tâches de maintenance | Maintenance du fichier de traces |
Dans certains cas, reconstruire périodiquement les index par la commande REINDEX(7) ou une série d'étapes individuelles de reconstruction en vaut la peine.
Les pages de l'index B-tree, qui sont devenues complètement vides, sont réclamées pour leur ré-utilisation. Mais, il existe toujours une possibilité d'utilisation peu efficace de l'espace : si, sur une page, seulement plusieurs clés d'index ont été supprimés, la page reste allouée. En conséquence, si seulement quelques clés sont supprimées, vous devrez vous attendre à ce que l'espace disque soit très mal utilisé. Dans de tels cas, la réindexation périodique est recommandée.
Le potentiel d'inflation des index qui ne sont pas des index B-tree n'a pas été particulièrement analysé. Surveiller périodiquement la taille physique de ces index est une bonne idée.
De plus, pour les index B-tree, un index tout juste construit est légèrement plus rapide qu'un index qui a été mis à jour plusieurs fois parce que les pages adjacentes logiquement sont habituellement aussi physiquement adjacentes dans un index nouvellement créé (cette considération ne s'applique pas aux index non B-tree). Il pourrait être intéressant de ré-indexer périodiquement simplement pour améliorer la vitesse d'accès.
REINDEX(7) peut être utilisé en toute sécurité et très facilement dans tous les cas. Mais comme cette commande nécessite un verrou exclusif sur la table, il est souvent préférable d'exécuter une reconstruction d'index avec une séquence d'étapes de création et remplacement. Les types d'index qui supportent CREATE INDEX(7) avec l'option CONCURRENTLY peuvent être recréés de cette façon. Si cela fonctionne et que l'index résultant est valide, l'index original peut être remplacé par le nouveau construit en utilisant une combinaison de ALTER INDEX(7) et DROP INDEX(7). Quand un index est utilisé pour forcer une contrainte d'unicité ou toute autre contrainte, ALTER TABLE(7) pourrait être nécessaire pour basculer la constrainte existante sur celle forcée par le nouvel index. Il faut mettre beaucoup d'attention dans la mise en place de cette reconstruction alternative à plusieurs étapes avant de l'utiliser car il existe des limitations pour lesquelles les index peuvent être réindexés de cette façon et les erreurs doivent être gérées.