Re: Point d'entrée

Bonjour,

Je cherche à trouver la méthode traitant les requêtes arrivant au niveau
d'un backend. Si quelqun est familier avec l'architecture de PostGreSQL
cela me ferait gagner beaucoup de temps

Merci

--
-- Jean Arnaud
-- Projet SARDES
-- INRIA Rhône-Alpes / LSR-IMAG
-- Tél. : +33 (0)4 76 61 52 80

Bonjour,
Pourriez vous nous en dire plus sur la finalité de votre question.
En effet, les requêtes arrivent au niveau du backend mais plusieurs
fonctions sont impliquées à des niveaux divers. S'il s'agit de rajouter
des mots clés etc... il s'agira plus de certaines fonctions, s'il s'agit
de faire d'autres opérations ça en sera d'autres. Avec cette précision,
nous pourrons vous donner une réponse mieux ciblée.

Cordialement,

Jean Arnaud m'expliquait (le 07.08.2006 17:43):

> Bonjour,
>
> Je cherche à trouver la méthode traitant les requêtes arrivant au
> niveau d'un backend. Si quelqun est familier avec l'architecture de
> PostGreSQL cela me ferait gagner beaucoup de temps
>
> Merci
>

--
Jean-Christophe Arnu
Paratronic

Jean-Christophe Arnu wrote:

>Bonjour,
> Pourriez vous nous en dire plus sur la finalité de votre question.
>En effet, les requêtes arrivent au niveau du backend mais plusieurs
>fonctions sont impliquées à des niveaux divers. S'il s'agit de rajouter
>des mots clés etc... il s'agira plus de certaines fonctions, s'il s'agit
>de faire d'autres opérations ça en sera d'autres. Avec cette précision,
>nous pourrons vous donner une réponse mieux ciblée.
>
>Cordialement,
>
>Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>
>
>
>>Bonjour,
>>
>>Je cherche à trouver la méthode traitant les requêtes arrivant au
>>niveau d'un backend. Si quelqun est familier avec l'architecture de
>>PostGreSQL cela me ferait gagner beaucoup de temps
>>
>>Merci
>>
>>
>>
>
>
>
Bonjour,

Je cherche à instrumenter le code pour obtenir des informations sur la
durée de traitement des requêtes. Je comptais donc chronometrer depuis
l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
trouver une méthode qui sera appelée au début de chaque traitement de
requête, et une autre à la fin. Je ne connais pas assez PostGreSQL pour
savoir si cette approche est naive ou réellement envisageable ?

--
-- Jean Arnaud

Bonjour,
vous pouvez le faire avec PostgreSQL dans les logs. Je ne sais pas
si c'est exactement ce que vous voulez faire mais vous avez une
directive de configuration dans postgresql.conf qui s'appelle
log_duration qui lorsqu'elle est mise à true (conjointement à
log_statement) permet de savoir le temps pris pour une requête. Voici
l'URL de la doc pour la configuration.
http://docs.postgresqlfr.org/8.1/runtime-config-logging.html

Par ailleurs, il existe un projet en ruby qui fait des stats sur les
requêtes à partir du log de postgresql lorsque ces options sont activées
: Practical Query Analysis : http://pgfoundry.org/projects/pqa/

Cordialement

Jean Arnaud m'expliquait (le 08.08.2006 10:18):

> Jean-Christophe Arnu wrote:
>
>> Bonjour,
>> Pourriez vous nous en dire plus sur la finalité de votre question.
>> En effet, les requêtes arrivent au niveau du backend mais plusieurs
>> fonctions sont impliquées à des niveaux divers. S'il s'agit de rajouter
>> des mots clés etc... il s'agira plus de certaines fonctions, s'il s'agit
>> de faire d'autres opérations ça en sera d'autres. Avec cette précision,
>> nous pourrons vous donner une réponse mieux ciblée.
>>
>> Cordialement,
>>
>> Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>>
>>
>>
>>> Bonjour,
>>>
>>> Je cherche à trouver la méthode traitant les requêtes arrivant au
>>> niveau d'un backend. Si quelqun est familier avec l'architecture de
>>> PostGreSQL cela me ferait gagner beaucoup de temps
>>>
>>> Merci
>>>
>>>
>>
>>
>>
>>
> Bonjour,
>
> Je cherche à instrumenter le code pour obtenir des informations sur la
> durée de traitement des requêtes. Je comptais donc chronometrer depuis
> l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
> trouver une méthode qui sera appelée au début de chaque traitement de
> requête, et une autre à la fin. Je ne connais pas assez PostGreSQL
> pour savoir si cette approche est naive ou réellement envisageable ?
>
>

--
Jean-Christophe Arnu
Paratronic

Rebonjour,

Ce sont en effet de bonnes solutions, mais j'ai fait mon propre outil de
statistiques qui doit calculer des critères de performance du serveur.
Sans avoir de très fortes contraintes temps-réel, le système doit être
assez réactif. Je cherche donc plutot à modifier le source
de PostGreSQL pour envoyer directement les informations à mon outil de
statistiques.

@+

Jean-Christophe Arnu wrote:

>Bonjour,
> vous pouvez le faire avec PostgreSQL dans les logs. Je ne sais pas
>si c'est exactement ce que vous voulez faire mais vous avez une
>directive de configuration dans postgresql.conf qui s'appelle
>log_duration qui lorsqu'elle est mise à true (conjointement à
>log_statement) permet de savoir le temps pris pour une requête. Voici
>l'URL de la doc pour la configuration.
>http://docs.postgresqlfr.org/8.1/runtime-config-logging.html
>
> Par ailleurs, il existe un projet en ruby qui fait des stats sur les
>requêtes à partir du log de postgresql lorsque ces options sont activées
>: Practical Query Analysis : http://pgfoundry.org/projects/pqa/
>
>Cordialement
>
>Jean Arnaud m'expliquait (le 08.08.2006 10:18):
>
>
>
>>Jean-Christophe Arnu wrote:
>>
>>
>>
>>>Bonjour,
>>> Pourriez vous nous en dire plus sur la finalité de votre question.
>>>En effet, les requêtes arrivent au niveau du backend mais plusieurs
>>>fonctions sont impliquées à des niveaux divers. S'il s'agit de rajouter
>>>des mots clés etc... il s'agira plus de certaines fonctions, s'il s'agit
>>>de faire d'autres opérations ça en sera d'autres. Avec cette précision,
>>>nous pourrons vous donner une réponse mieux ciblée.
>>>
>>>Cordialement,
>>>
>>>Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>>>
>>>
>>>
>>>
>>>
>>>>Bonjour,
>>>>
>>>>Je cherche à trouver la méthode traitant les requêtes arrivant au
>>>>niveau d'un backend. Si quelqun est familier avec l'architecture de
>>>>PostGreSQL cela me ferait gagner beaucoup de temps
>>>>
>>>>Merci
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>Bonjour,
>>
>>Je cherche à instrumenter le code pour obtenir des informations sur la
>>durée de traitement des requêtes. Je comptais donc chronometrer depuis
>>l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
>>trouver une méthode qui sera appelée au début de chaque traitement de
>>requête, et une autre à la fin. Je ne connais pas assez PostGreSQL
>>pour savoir si cette approche est naive ou réellement envisageable ?
>>
>>
>>
>>
>
>
>

--
-- Jean Arnaud
-- Projet SARDES
-- INRIA Rhône-Alpes / LSR-IMAG
-- Tél. : +33 (0)4 76 61 52 80

Effectivement, je comprends mieux votre besoin. Dans ce cas, je vous
recommande de jeter un oeil à src/backend/tcop/postgresql.c fonctions
- exec_simple_query()
- exec_execute_message()
Ces deux fonctions sont utilisées dans le logging initial de
postgresql. Un petit hack à ce niveau vous permettra de transmettre le
start et le stop d'une requête et le passer à une de vos fonctions?

Cordialement,

Jean Arnaud m'expliquait (le 08.08.2006 12:28):

> Rebonjour,
>
> Ce sont en effet de bonnes solutions, mais j'ai fait mon propre outil
> de statistiques qui doit calculer des critères de performance du serveur.
> Sans avoir de très fortes contraintes temps-réel, le système doit être
> assez réactif. Je cherche donc plutot à modifier le source
> de PostGreSQL pour envoyer directement les informations à mon outil de
> statistiques.
>
> @+
>
> Jean-Christophe Arnu wrote:
>
>> Bonjour,
>> vous pouvez le faire avec PostgreSQL dans les logs. Je ne sais pas
>> si c'est exactement ce que vous voulez faire mais vous avez une
>> directive de configuration dans postgresql.conf qui s'appelle
>> log_duration qui lorsqu'elle est mise à true (conjointement à
>> log_statement) permet de savoir le temps pris pour une requête. Voici
>> l'URL de la doc pour la configuration.
>> http://docs.postgresqlfr.org/8.1/runtime-config-logging.html
>>
>> Par ailleurs, il existe un projet en ruby qui fait des stats sur les
>> requêtes à partir du log de postgresql lorsque ces options sont activées
>> : Practical Query Analysis : http://pgfoundry.org/projects/pqa/
>>
>> Cordialement
>>
>> Jean Arnaud m'expliquait (le 08.08.2006 10:18):
>>
>>
>>
>>> Jean-Christophe Arnu wrote:
>>>
>>>
>>>
>>>> Bonjour,
>>>> Pourriez vous nous en dire plus sur la finalité de votre question.
>>>> En effet, les requêtes arrivent au niveau du backend mais plusieurs
>>>> fonctions sont impliquées à des niveaux divers. S'il s'agit de
>>>> rajouter
>>>> des mots clés etc... il s'agira plus de certaines fonctions, s'il
>>>> s'agit
>>>> de faire d'autres opérations ça en sera d'autres. Avec cette
>>>> précision,
>>>> nous pourrons vous donner une réponse mieux ciblée.
>>>>
>>>> Cordialement,
>>>>
>>>> Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Bonjour,
>>>>>
>>>>> Je cherche à trouver la méthode traitant les requêtes arrivant au
>>>>> niveau d'un backend. Si quelqun est familier avec l'architecture de
>>>>> PostGreSQL cela me ferait gagner beaucoup de temps
>>>>>
>>>>> Merci
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> Bonjour,
>>>
>>> Je cherche à instrumenter le code pour obtenir des informations sur la
>>> durée de traitement des requêtes. Je comptais donc chronometrer depuis
>>> l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
>>> trouver une méthode qui sera appelée au début de chaque traitement de
>>> requête, et une autre à la fin. Je ne connais pas assez PostGreSQL
>>> pour savoir si cette approche est naive ou réellement envisageable ?
>>>
>>>
>>>
>>
>>
>>
>>
>
>

--
Jean-Christophe Arnu
Paratronic

Jean-Christophe Arnu wrote:

>Effectivement, je comprends mieux votre besoin. Dans ce cas, je vous
>recommande de jeter un oeil à src/backend/tcop/postgresql.c fonctions
> - exec_simple_query()
> - exec_execute_message()
> Ces deux fonctions sont utilisées dans le logging initial de
>postgresql. Un petit hack à ce niveau vous permettra de transmettre le
>start et le stop d'une requête et le passer à une de vos fonctions?
>
>Cordialement,
>
>

Voilà c'est exactement ce que je cherchais :)
Que signifie "tcop" ?

Merci

>Jean Arnaud m'expliquait (le 08.08.2006 12:28):
>
>
>
>>Rebonjour,
>>
>>Ce sont en effet de bonnes solutions, mais j'ai fait mon propre outil
>>de statistiques qui doit calculer des critères de performance du serveur.
>>Sans avoir de très fortes contraintes temps-réel, le système doit être
>>assez réactif. Je cherche donc plutot à modifier le source
>>de PostGreSQL pour envoyer directement les informations à mon outil de
>>statistiques.
>>
>>@+
>>
>>Jean-Christophe Arnu wrote:
>>
>>
>>
>>>Bonjour,
>>> vous pouvez le faire avec PostgreSQL dans les logs. Je ne sais pas
>>>si c'est exactement ce que vous voulez faire mais vous avez une
>>>directive de configuration dans postgresql.conf qui s'appelle
>>>log_duration qui lorsqu'elle est mise à true (conjointement à
>>>log_statement) permet de savoir le temps pris pour une requête. Voici
>>>l'URL de la doc pour la configuration.
>>>http://docs.postgresqlfr.org/8.1/runtime-config-logging.html
>>>
>>> Par ailleurs, il existe un projet en ruby qui fait des stats sur les
>>>requêtes à partir du log de postgresql lorsque ces options sont activées
>>>: Practical Query Analysis : http://pgfoundry.org/projects/pqa/
>>>
>>>Cordialement
>>>
>>>Jean Arnaud m'expliquait (le 08.08.2006 10:18):
>>>
>>>
>>>
>>>
>>>
>>>>Jean-Christophe Arnu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Bonjour,
>>>>> Pourriez vous nous en dire plus sur la finalité de votre question.
>>>>>En effet, les requêtes arrivent au niveau du backend mais plusieurs
>>>>>fonctions sont impliquées à des niveaux divers. S'il s'agit de
>>>>>rajouter
>>>>>des mots clés etc... il s'agira plus de certaines fonctions, s'il
>>>>>s'agit
>>>>>de faire d'autres opérations ça en sera d'autres. Avec cette
>>>>>précision,
>>>>>nous pourrons vous donner une réponse mieux ciblée.
>>>>>
>>>>>Cordialement,
>>>>>
>>>>>Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Bonjour,
>>>>>>
>>>>>>Je cherche à trouver la méthode traitant les requêtes arrivant au
>>>>>>niveau d'un backend. Si quelqun est familier avec l'architecture de
>>>>>>PostGreSQL cela me ferait gagner beaucoup de temps
>>>>>>
>>>>>>Merci
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Bonjour,
>>>>
>>>>Je cherche à instrumenter le code pour obtenir des informations sur la
>>>>durée de traitement des requêtes. Je comptais donc chronometrer depuis
>>>>l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
>>>>trouver une méthode qui sera appelée au début de chaque traitement de
>>>>requête, et une autre à la fin. Je ne connais pas assez PostGreSQL
>>>>pour savoir si cette approche est naive ou réellement envisageable ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

--
-- Jean Arnaud
-- Projet SARDES
-- INRIA Rhône-Alpes / LSR-IMAG
-- Tél. : +33 (0)4 76 61 52 80

Je pense qu'il s'agit de traffic cop :

* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/tcop/postgres.c,v 1.468.2.4
2006/04/18 00:52:41 momjian Exp $
*
* NOTES
* this is the "main" module of the postgres backend and
* hence the main module of the "traffic cop".
*
*-------------------------------------------------------------------------

Voir : http://www.postgresql.org/files/developer/history.pdf pour plus
d'information.

D'autres informations :
http://www.postgresql.org/developer/ext.backend_dirs.html

où il est dit :

tcop
<http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop>
- traffic cop, dispatches request to proper module

This contains the /postgres/ backend main handler, as well as the code
that makes calls to the parser, optimizer, executor, and //commands/
functions.

Jean Arnaud m'expliquait (le 08.08.2006 15:04):

> Jean-Christophe Arnu wrote:
>
>> Effectivement, je comprends mieux votre besoin. Dans ce cas, je vous
>> recommande de jeter un oeil à src/backend/tcop/postgresql.c fonctions
>> - exec_simple_query()
>> - exec_execute_message()
>> Ces deux fonctions sont utilisées dans le logging initial de
>> postgresql. Un petit hack à ce niveau vous permettra de transmettre le
>> start et le stop d'une requête et le passer à une de vos fonctions?
>>
>> Cordialement,
>>
>>
>
> Voilà c'est exactement ce que je cherchais :)
> Que signifie "tcop" ?
>
> Merci
>
>> Jean Arnaud m'expliquait (le 08.08.2006 12:28):
>>
>>
>>
>>> Rebonjour,
>>>
>>> Ce sont en effet de bonnes solutions, mais j'ai fait mon propre outil
>>> de statistiques qui doit calculer des critères de performance du
>>> serveur.
>>> Sans avoir de très fortes contraintes temps-réel, le système doit être
>>> assez réactif. Je cherche donc plutot à modifier le source
>>> de PostGreSQL pour envoyer directement les informations à mon outil de
>>> statistiques.
>>>
>>> @+
>>>
>>> Jean-Christophe Arnu wrote:
>>>
>>>
>>>
>>>> Bonjour,
>>>> vous pouvez le faire avec PostgreSQL dans les logs. Je ne sais pas
>>>> si c'est exactement ce que vous voulez faire mais vous avez une
>>>> directive de configuration dans postgresql.conf qui s'appelle
>>>> log_duration qui lorsqu'elle est mise à true (conjointement à
>>>> log_statement) permet de savoir le temps pris pour une requête. Voici
>>>> l'URL de la doc pour la configuration.
>>>> http://docs.postgresqlfr.org/8.1/runtime-config-logging.html
>>>>
>>>> Par ailleurs, il existe un projet en ruby qui fait des stats sur les
>>>> requêtes à partir du log de postgresql lorsque ces options sont
>>>> activées
>>>> : Practical Query Analysis : http://pgfoundry.org/projects/pqa/
>>>>
>>>> Cordialement
>>>>
>>>> Jean Arnaud m'expliquait (le 08.08.2006 10:18):
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Jean-Christophe Arnu wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Bonjour,
>>>>>> Pourriez vous nous en dire plus sur la finalité de votre question.
>>>>>> En effet, les requêtes arrivent au niveau du backend mais plusieurs
>>>>>> fonctions sont impliquées à des niveaux divers. S'il s'agit de
>>>>>> rajouter
>>>>>> des mots clés etc... il s'agira plus de certaines fonctions, s'il
>>>>>> s'agit
>>>>>> de faire d'autres opérations ça en sera d'autres. Avec cette
>>>>>> précision,
>>>>>> nous pourrons vous donner une réponse mieux ciblée.
>>>>>>
>>>>>> Cordialement,
>>>>>>
>>>>>> Jean Arnaud m'expliquait (le 07.08.2006 17:43):
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> Je cherche à trouver la méthode traitant les requêtes arrivant au
>>>>>>> niveau d'un backend. Si quelqun est familier avec l'architecture de
>>>>>>> PostGreSQL cela me ferait gagner beaucoup de temps
>>>>>>>
>>>>>>> Merci
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Bonjour,
>>>>>
>>>>> Je cherche à instrumenter le code pour obtenir des informations
>>>>> sur la
>>>>> durée de traitement des requêtes. Je comptais donc chronometrer
>>>>> depuis
>>>>> l'arrivée de la requête jusqu'à l'envoi du résultat. Il me faut donc
>>>>> trouver une méthode qui sera appelée au début de chaque traitement de
>>>>> requête, et une autre à la fin. Je ne connais pas assez PostGreSQL
>>>>> pour savoir si cette approche est naive ou réellement envisageable ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>

--
Jean-Christophe Arnu
Paratronic

Le Tue, 08 Aug 2006 15:04:32 +0200
Jean Arnaud <Jean(dot)Arnaud(at)inrialpes(dot)fr> a écrit:

>
> Voilà c'est exactement ce que je cherchais :)
> Que signifie "tcop" ?
>
En américain cournat un cop est un flic et
traffic cop semble pouvoir se traduir par
"agent de la circulation".

--
Alain Lucari (Eurlix)