Re: query logging of prepared statements

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: query logging of prepared statements
Date: 2019-04-06 01:16:38
Message-ID: 20190406011638.pgb7uxjz2hnhavsu@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

On 2019-04-04 16:01:26 -0300, Alvaro Herrera wrote:
> Also, if you parse once and bind/execute many times, IMO the statement
> should be logged exactly once. I think you could that with the flag I
> propose.

I'm not actually sure I buy this. Consider e.g. log analysis for
workloads with long-running connections. If most statements are just
already prepared statements - pretty common in higher throughput apps -
the query will suddenly be either far away in the logfile (thereby
requiring pretty expensive analysis to figure out the corresponding
statement) or even in a different logfile due to rotation.

I'm sympathetic to the desire to reduce log volume, but I'm fearful this
would make log analysis much harder. Searching through many gigabytes
just to find the query text of the statement being executed over and
over doesn't sound great.

I think deduplicating the logging between bind and execute has less of
that hazard.

- Andres

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2019-04-06 05:51:32 Re: 10.2: high cpu usage on update statement
Previous Message Kevin Wilkinson 2019-04-05 22:45:26 10.2: high cpu usage on update statement

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-04-06 01:23:35 Re: New vacuum option to do only freezing
Previous Message David Rowley 2019-04-06 00:45:25 Re: Ordered Partitioned Table Scans