Pourquoi mon PostgreSQL `SELECT DISTINCT` est-il si lent et comment puis-je y remédier ?

PostgreSQL SELECT DISTINCT Goulot d'étranglement des performances : une étude de cas

Cet article examine les problèmes de performances rencontrés avec une SELECT DISTINCT requête sur une table PostgreSQL contenant environ deux millions d'enregistrements.

Contexte

La table tickers stocke les données du canal « ticker » de Coinbase Pro. Une clé primaire composite comprend la colonne product_id.

Problème de performances

La requête SELECT DISTINCT product_id FROM tickers devait fonctionner correctement en raison de l'index sur product_id. Cependant, l'exécution prenait systématiquement 500 à 600 millisecondes.

Enquête sur le plan de requête

EXPLAIN ANALYZE a montré que le planificateur de requêtes utilisait par défaut une analyse séquentielle, ignorant l'index product_id. Forcer l'utilisation de l'index n'a pas résolu le problème de performances.

Tentatives d'optimisation d'index

La création d'un index dédié sur product_id n'a apporté que des améliorations mineures, les analyses séquentielles étant toujours préférées par le planificateur, à moins qu'elles ne soient explicitement remplacées.

Solution efficace : émulation d'analyse par saut d'index

La solution implémentée émule les analyses de saut d'index à l'aide de requêtes récursives avec jointures latérales. Cette approche a considérablement amélioré les performances, réduisant le temps d'exécution à 0,75 milliseconde, même avec un ensemble de données de 2,25 millions de lignes.

Résumé

Le manque actuel de fonctionnalités natives d'analyse des sauts d'index de PostgreSQL est résolu par cette technique d'émulation. Cette méthode utilise efficacement les index existants et évite la pénalité de performances liée aux analyses séquentielles pour les SELECT DISTINCT requêtes sur les grandes tables.

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!