Re: Point d'entrée

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