From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Iwata, Aya" <iwata.aya@jp.fujitsu.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: libpq debug log
In-reply-to: <71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25>
References: <71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25>
Comments: In-reply-to "Iwata, Aya" <iwata.aya@jp.fujitsu.com>
	message dated "Fri, 24 Aug 2018 04:38:22 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25773.1535118514.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Aug 2018 09:48:34 -0400
Message-ID: <25774.1535118514@sss.pgh.pa.us>
Precedence: bulk

"Iwata, Aya" <iwata.aya@jp.fujitsu.com> writes:
> I'm going to propose libpq debug log for analysis of queries on the appl=
ication side.
> I think that it is useful to determine whether the cause is on the appli=
cation side or the server side when a slow query occurs. =


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 proces=
sing is started, "query", "application side processing", which is picked u=
p information from PQtrace(), and "connection id", which is for uniquely i=
dentifying 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