En supposant que vous posiez des questions sur la fonctionnalité commune "d'indication d'index" trouvée dans de nombreuses bases de données, PostgreSQL ne fournit pas une telle fonctionnalité. C'était une décision consciente prise par l'équipe PostgreSQL. Un bon aperçu de pourquoi et de ce que vous pouvez faire à la place peut être trouvé ici. Les raisons sont essentiellement qu'il s'agit d'un hack de performances qui a tendance à causer plus de problèmes plus tard à mesure que vos données changent, alors que l'optimiseur de PostgreSQL peut réévaluer le plan en fonction des statistiques. En d'autres termes, ce qui pourrait être un bon plan de requête aujourd'hui ne sera probablement pas un bon plan de requête pour toujours, et les indices d'index forcent un plan de requête particulier pour toujours.
En tant que marteau très émoussé, utile pour les tests, vous pouvez utiliser le enable_seqscan et enable_indexscan paramètres. Voir :
- Examiner l'utilisation de l'index
enable_paramètres
Ceux-ci ne sont pas adaptés à une utilisation en production continue . Si vous rencontrez des problèmes avec le choix du plan de requête, vous devriez consulter la documentation pour suivre les problèmes de performances des requêtes. Ne vous contentez pas de définir enable_ params et partez.
À moins que vous n'ayez une très bonne raison d'utiliser l'index, Postgres peut faire le bon choix. Pourquoi ?
- Pour les petites tables, il est plus rapide d'effectuer des analyses séquentielles.
- Postgres n'utilise pas d'index lorsque les types de données ne correspondent pas correctement, vous devrez peut-être inclure des transtypages appropriés.
- Les paramètres de votre planificateur peuvent poser problème.
Voir aussi cet ancien message de groupe de discussion.
