Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
En voulant faire baisser la durée d'une requête SELECT, j'ai ajouté un index qui n'a rien changé (ou si peu) à la durée d'exécution mais qui a (environ) divisé par 2 le cost (valeur la plus grande trouvée sur la première ligne du EXPLAIN ANALYZE).
Naivement (et à défaut d'arriver à faire baisser la durée de la requête), je me dis que pour la même durée, arriver à baisser le cost, c'est bien.
Est-ce que je me trompe ?
Comment expliquer obtenir un meilleur cost sans gain sur la durée d'exécution ?
Ludovic
Hors ligne
Bonjour,
C'est un sujet un peu compliqué. Le coût estimé d'une requête, c'est vraiment quelque chose qui est estimé à la louche (en partant des statistiques sur les données). Faire baisser le coût, c'est un bon indicateur que c'est probablement mieux, mais pas une preuve absolue, loin de là, malheureusement. Par exemple si il y a une grosse erreur d'estimation (ce qui peut arriver pour plein de raisons… stats insuffisantes, paramètres de la requête un peu hors des valeurs types, nombreuses jointures qui empilent les erreurs d'estimations, etc…), le coût le moins élevé n'est pas forcément le meilleur. Mais bon, on va dire que par défaut, un moindre coût c'est mieux.
C'est pour ça qu'on a les options d'EXPLAIN comme ANALYZE, BUFFERS qui permettent de voir ce qui se passe lors d'une réelle exécution pour comparer
Si vous voulez vraiment comprendre le sujet, la doc explique pas mal de choses, et on trouve maintenant pas mal d'enregistrements de conférences, sur youtube par exemple, sur le sujet.
Marc.
Hors ligne
Merci pour votre retour.
Effectivement, j'ai déjà été confronté aux raisons invoquées ...
Pour mon cas, je disais diviser environ de moitié le cost général mais sur le nœud qui m'intéresse (la lecture d'une table précise sur lequel j'ai ajouté l'index), j'ai une baisse de 63 % (de 61241 à 22401).
Je vais me permettre de penser que c'est déjà pas mal 
Ludovic
Hors ligne
Pages : 1
