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
Date: Fri, 24 Aug 2018 09:48:34 -0400
Message-ID: <25774.1535118514@sss.pgh.pa.us> (raw)
In-Reply-To: <71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25>
References: <71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25>
"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 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 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, iwata.aya@jp.fujitsu.com
Subject: Re: libpq debug log
In-Reply-To: <25774.1535118514@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox