Dans certains cas, reconstruire périodiquement les index par la commande REINDEX vaut la peine.

Dans les versions PostgreSQL™ antérieures à la 7.4, la réindexation périodique était fréquemment nécessaire pour éviter l'« inflation des index », à cause d'un manque de récupération de l'espace interne dans les index B-tree. Toutes les situations dans lesquelles l'échelle des clés d'index change dans le temps -- par exemple, un index sur l'horodatage dans une table où les anciennes entrées sont finalement supprimées -- pourraient résulter en une inflation car les pages d'index des portions inutilisées de cet ensemble n'étaient pas réclamées pour être ré-utilisées. Au bout d'un certain temps, la taille de l'index pouvait devenir indéfiniment plus large que les données utiles qu'elle contient.

Dans les versions 7.4 et ultérieures de PostgreSQL™, les pages d'index qui sont devenues complètement vides sont récupérées pour être réutilisées. Il existe toujours une possibilité d'une utilisation inefficace de l'espace : si pratiquement toutes les clés d'index d'une page ont été supprimées, la page reste allouée. Donc, le cas d'une utilisation où la majorité des clés de l'index d'une page est supprimée est un cas où l'espace sera mal utilisé. Pour de tels usages, une 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é. Garder un œil sur la taille physique de ces index est une bonne idée.

De plus, pour les index B-tree, un index tout juste construit est quelque peu 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.