PostgreSQL SELECT DISTINCT
Goulots d'étranglement des performances et stratégies d'optimisation
Une SELECT DISTINCT
requête sur une table PostgreSQL contenant près de deux millions d'enregistrements présente des performances étonnamment lentes (500 à 600 ms). Le planificateur de requêtes utilise inexplicablement par défaut une analyse séquentielle au lieu d'exploiter un index disponible, et même le forçage d'index n'améliore pas de manière significative le temps d'exécution.
Émulation de l'analyse des sauts d'index dans PostgreSQL
Étant donné que PostgreSQL ne dispose pas de fonctionnalité native d'analyse des sauts d'index, une solution de contournement utilisant une expression de table commune (CTE) récursive peut imiter son comportement. Ce CTE récupère de manière itérative des ID de produits distincts par ordre croissant, en utilisant un index sur product_id
pour plus d'efficacité :
<code class="language-sql">WITH RECURSIVE cte AS ( ( SELECT product_id FROM tickers ORDER BY 1 LIMIT 1 ) UNION ALL SELECT l.* FROM cte c CROSS JOIN LATERAL ( SELECT product_id FROM tickers t WHERE t.product_id > c.product_id ORDER BY 1 LIMIT 1 ) l ) SELECT * FROM cte;</code>
Cette approche offre un gain de performances substantiel par rapport à une analyse de table complète.
Approches alternatives : DISTINCT
et DISTINCT ON
Pour les tableaux avec une répartition plus uniforme des lignes par ID de produit unique, les mots-clés standard DISTINCT
ou DISTINCT ON
peuvent s'avérer plus rapides que l'analyse de saut d'index émulée. Leurs performances dépendent fortement de la distribution des données.
Améliorations futures : analyse des sauts d'index natif
Le développement de PostgreSQL inclut un travail en cours pour intégrer les capacités natives d'analyse des sauts d'index. Cette future amélioration promet de nouvelles optimisations des performances pour les SELECT DISTINCT
requêtes.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!