PostgreSQL : indexer les requêtes réelles, pas les intuitions

Partir de la requête qui pose problème

Ajouter un index sur toutes les colonnes n'est pas une stratégie. Je pars d'une requête représentative : par exemple les réservations récentes d'un compte, filtrées par statut et triées par date. Je relève son temps d'exécution, la taille des tables et la fréquence de l'opération.

Examiner avant de modifier

Avec EXPLAIN, puis EXPLAIN ANALYZE dans un environnement adapté, je regarde le plan choisi et les lignes réellement parcourues. Un index sur une colonne filtrée peut aider, mais son intérêt dépend de la sélectivité, du tri et des volumes. Les écritures et le stockage paient aussi le coût de chaque index supplémentaire.

Pour une application multi-tenant, la clé du tenant doit être présente dans les requêtes concernées et dans la réflexion sur les index. L'index ne corrige pas une requête qui oublie d'isoler les données d'un tenant : c'est d'abord une question de sécurité et de modèle de données.

Je mesure à nouveau après changement, avec des données proches de la réalité, puis je conserve l'index seulement si le gain justifie son coût.

Pour aller plus loin : index PostgreSQL et EXPLAIN.