Pour tester fins, vous pouvez forcer l'utilisation de l'index en "désactivant" les analyses séquentielles - de préférence dans votre session en cours uniquement :
SET enable_seqscan = OFF;
Ne pas utilisez-le sur un serveur productif. Détails dans le manuel ici.
J'ai cité "désactivation", car vous ne pouvez pas réellement désactiver les analyses de table séquentielles. Mais toute autre option disponible est désormais préférable pour Postgres. Cela prouvera que l'index multicolonne sur (metric_id, t) peut être utilisé - mais pas aussi efficace qu'un index sur la colonne de tête.
Vous obtiendrez probablement de meilleurs résultats en changeant l'ordre des colonnes dans votre PRIMARY KEY (et l'index utilisé pour l'implémenter derrière les rideaux) à (t, metric_id) . Ou créez un supplément index avec des colonnes inversées comme ça.
- Un index composite est-il également adapté aux requêtes sur le premier champ ?
Vous n'avez normalement pas besoin de forcer de meilleurs plans de requête par une intervention manuelle. Si le réglage enable_seqscan = OFF mène à beaucoup meilleur plan, quelque chose ne va probablement pas dans votre base de données. Considérez cette réponse connexe :
- Empêcher PostgreSQL de choisir parfois un mauvais plan de requête
