Re: libpq debug log

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq debug log
Дата
Msg-id 25774.1535118514@sss.pgh.pa.us
обсуждение исходный текст
Ответ на libpq debug log  ("Iwata, Aya" <iwata.aya@jp.fujitsu.com>)
Ответы Re: libpq debug log  (Robert Haas <robertmhaas@gmail.com>)
RE: libpq debug log  ("Iwata, Aya" <iwata.aya@jp.fujitsu.com>)
Список pgsql-hackers
"Iwata, Aya" <iwata.aya@jp.fujitsu.com> writes:
> I'm going to propose libpq debug log for analysis of queries on the application side.
> I think that it is useful to determine whether the cause is on the application side or the server side when a slow
queryoccurs.  

Hm, how will you tell that really?  And what's the advantage over the
existing server-side query logging capability?

> The provided information is "date and time" at which execution of processing is started, "query", "application side
processing",which is picked up information from PQtrace(), and "connection id", which is for uniquely identifying the
connection. 

PQtrace() is utterly useless for anything except debugging libpq
internals, and it's not tremendously useful even for that.  Don't
bother with that part.

Where will you get a "unique connection id" from?

How will you deal with asynchronously-executed queries --- either
the PQgetResult style, or the single-row-at-a-time style?

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: document that MergeAppend can now prune