Requête très rapide dans pgadmin et très lente dans les logs, où est le problème ?

[Michael REMY]

bonjour,

Sous pg82 sous windows, j'ai activé les logs à 100ms.

dedans je vois des requêtes avec les durées.
quand je fais un copie-collé dans pgadmin, la durée est totalement différente qu'en log.
pourquoi ?

par exemple cette requête :

Code :

SELECT lower(calevent_resources.VIEW),liste_dates FROM calevent_resources,calevent_item WHERE calevent_item.id=calevent_item_id  AND res_model='sale.order' AND order_id=7261 ORDER BY date_premiere

est logée à "duration: 1014.999 ms"

alors qu'un copié-collé de son sql dans pgadmin ne prend que 20ms !


pourquoi ?

J'ai plein de requêtes comme ça en fait !


avez-vous une idée du pourquoi cette différence énorme ?

[estofilo]

Ca peut être dû au cache disque.
Quand les données sont en cache, les requêtes sont évidemment plus rapides.

Ca peut aussi être dû tout simplement au fait que la machine avait d'autres choses à faire que la requête lente à ce moment là.

[Michael REMY]

Envoyé par estofilo

Ca peut être dû au cache disque.
Quand les données sont en cache, les requêtes sont évidemment plus rapides.

Ca peut aussi être dû tout simplement au fait que la machine avait d'autres choses à faire que la requête lente à ce moment là.

c'est bien malheureux tout ça ! Le log me dit qu'une requête prend du temps
mais je ne connais pas les conditions d'éxécutions...

à moins que je ne puisse aussi connaître et loggé l'état du cpu (% utilisation) au moment de l'éxecution de la requête.
Mais j'ai bien regardé les possibilités de logs, il n'y en a aucune qui me donne l'état du cpu :

log_line_prefix = '%t ' # Special values:
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = PID
# %t = timestamp (no milliseconds)
# %m = timestamp with milliseconds
# %i = command tag
# %c = session id
# %l = session line number
# %s = session start timestamp
# %x = transaction id
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '

à moins que ce ne soit autre part?

[punkoff]

Ca peut aussi venir d'un lock.

Mais vu qu'il n'y a pas d'outil en natif pour analyser correctement ce que fait le sgbd ...

pour la partie système va falloir recouper avec des outils d'analyse de votre systeme d'exploitation.
http://wiki.postgresql.org/wiki/Perf...Analysis_Tools