Vous n'êtes pas identifié(e).
Bonjour,
Je ne parviens pas à comprendre pourquoi un actual time n'est pas une valeur fixe mais une fourchette (dans l'exemple suivant une fourchette de 0,661 à 0,672 ms)
exemple :
(actual time=0.661..0.672 rows=7 loops=1)
Par avance merci.
CDT
Hors ligne
Ce n'est pas une fourchette. Le premier élément indique le temps pour récupérer la première ligne et le deuxième élément indique le temps pour récupérer toutes les lignes. Le plus intéressant est généralement le deuxième mais le premier a aussi son importance dans le choix du plan d'exécution par PostgreSQL.
Guillaume.
Hors ligne
Merci.
"Recupérer la première ligne"
qu'entendez vous par "ligne" ? S'agit il de "rows" qui sont en l'occurrence au nombre de 7 ?
Hors ligne
oui
Hors ligne
C'est ça, la première ligne de l'ensemble de résultats pour le noeud en question.
Guillaume.
Hors ligne
Merci.
Mon réflexe avait été de multiplier par 7 le temps mis pour récupérer la première ligne de manière à obtenir le temps mis pour les 7 lignes. Je suppose que l'index permet justement de s'affranchir de ce coût.
Par contre, dans le cas d'une recherche séquentielle, sans index donc, c'est grosso modo une telle multiplication qu'il faut faire ? Ou c'est bien plus compliqué ?
Ou bien je suis totalement à coté de la plaque ? 
Hors ligne
J'ai du mal à croire que vous aurez moins de 0,6 ms, y compris avec un index
Le temps qui est indiqué est le temps total, que ce soit un parcours séquentiel, un parcours d'index, une nested loop, un hash join, etc. Pas besoin de multiplier quoi que ce soit.
Guillaume.
Hors ligne
D'accord.
Maintenant, imaginons que le SGBD ait à faire un choix parmi plusieurs possibilités. Le temps mis pour évaluer les autres possibilités (index, recherche séquentielle... qui ne seront pas retenus) est il comptabilisé dans cet 'actual time' ou pas du tout ou ailleurs (total runtime ?) ?
Hors ligne
oubliez ma dernière question.
Ces temps (actual time) calculés, peuvent ils varier si on fait plusieurs fois le mêmes EXPLAIN ANALYSE ?
Hors ligne
Maintenant, imaginons que le SGBD ait à faire un choix parmi plusieurs possibilités. Le temps mis pour évaluer les autres possibilités (index, recherche séquentielle... qui ne seront pas retenus) est il comptabilisé dans cet 'actual time' ou pas du tout ou ailleurs (total runtime ?) ?
Il est intégré au "total runtime". Normalement, il devrait être insignifiant mais il peut arriver que cela ne soit pas le cas.
Ces temps (actual time) calculés, peuvent ils varier si on fait plusieurs fois le mêmes EXPLAIN ANALYSE ?
Oui. C'est typiquement le cas quand vous exécutez la requête une première fois, les données devant être lues sur disque pour être mise en cache, et plusieurs fois après où les données sont directement accessibles du cache. Mais ça peut être aussi pour un tas d'autres raisons. Pour exemple, dans un cas, vous êtes seul à travailler sur le serveur, et dans un autre cas, vous êtes plusieurs à exécuter des requêtes (ou plus exactement à travailler sur le serveur).
Guillaume.
Hors ligne
