Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je voulais savoir comment bien configurer la vue pg_stat_statement sous postgres 8.4 afin d'avoir uniquement les requêtes des utilisateurs.
En effet, pour l'instant, toute les select effectués sur la base de données sont enregistrés meme ceux system.
Si vous avez des conseils de gestion ou des alternative, le but etant de tracer les requetes longues afin de pouvoir les optimiser.
Merci pour vos reponses,
Cordialement
Hors ligne
Il n'y a pas vraiment de requêtes « systèmes ». Qu'est-ce pour vous qu'une requête système ?
Guillaume.
Hors ligne
Les select effectués lors de la navigation sur PgAdminIII
Hors ligne
Non, pas possible, ce sont des requêtes comme les autres. N'importe qui pourrait lancer ce type de requêtes.
Guillaume.
Hors ligne
Si le but est de tracer les requêtes longues, est-ce que les tracer dans les logs pourrait convenir?
En réglant le paramètre log_min_duration_statement (integer)
http://docs.postgresql.fr/8.4/runtime-c … gging.html
Désolée si je suis un peu hors-sujet, mais le but de tracer les requêtes longues m'y a fait penser.
Hors ligne
Merci mais le but serait de pouvoir avoir une trace des requetes longues, courtes mais utilisées un grand nombre de fois, et surtout les requetes qui font des deadlocks ou qui sont en attente d'une table verrouillée.
Bref d'avoir un bon nombre des requêtes mais seulement celles utilisateur ( langage procédurale )...
Si ce n'est pas clair n'hésitez pas a le signaler.
Hors ligne
C'est très clair et la réponse l'est aussi. Non, c'est impossible. Il n'y a aucun moyen de distinguer les requêtes de pgAdmin des autres. Pas plus qu'il est possible de distinguer les requêtes de pg_dump des autres.
Un moyen apparaîtra en 9.0 vu qu'il sera possible de demander la trace du nom de l'application. Il suffira dans ce cas là de ne pas prendre en compte les traces parlant de pgadmin ou de pg_dump.
Mais actuellement, il n'y a aucun moyen pour le faire.
Guillaume.
Hors ligne
Non pas celles de PgAdmin mais des utilisateurs ( qui passe par une application qui utilise un lien ODBC)
Hors ligne
Peut-être que le pilote ODBC permettrait de le faire.
Guillaume.
Hors ligne
De quelle façon?
Tracer les requêtes longues ou qui effectuent des deadlocks?
Hors ligne
Merci mais le but serait de pouvoir avoir une trace des requetes longues, courtes mais utilisées un grand nombre de fois, et surtout les requetes qui font des deadlocks ou qui sont en attente d'une table verrouillée.
Bonjour,
J'ai l'impression que nous partons sur de faux problèmes. Je m'explique : votre problème est de repérer les requêtes dont les performances ont un impact sur les utilisateurs, non? (requêtes longues, requêtes courtes mais surchargeant les bases, les requêtes en attente). Je suppose que ces requêtes sont les requêtes d'une ou plusieurs applications dont vous cherchez à contrôler et/ou améliorer les performances? Dans ce cas, je ne pense pas que la présence de quelques requêtes effectuées via pgAdmin vous gêne beaucoup.
Les outils que vous pouvez utiliser pour répondre à vos besoins sont :
pg_stat_statements pour les requêtes longues, et pour les courtes exécutées fréquemment,
log_min_duration pour avoir la trace des requêtes les plus longues dans la log,
Les deadlocks sont tracés dans la log.
Il y a également quelque chose qui me gêne dans votre formulation : "en attente d'une table verrouillée". Hors une table ne peut être verrouillée que par une modification de structure de la table (ALTER TABLE ...). Sinon, seules les lignes peuvent être verrouillées (et en mode READ COMMITTED, seuls les écritures verrouillent, et elles verrouillent seulement les autres écritures sur la même ligne). Êtiez-vous au courant de ce fait?
Hors ligne
Pages : 1
