Re: query logging of prepared statements

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(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-07 15:31:01
Message-ID: 20190407153101.GA10080@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

Thanks both for thinking about this.

On Fri, Apr 05, 2019 at 06:16:38PM -0700, Andres Freund wrote:
> 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 think deduplicating the logging between bind and execute has less of
> that hazard.

Do you mean the bind parameters, which are only duplicated in the case of
log_min_duration_statement ?

I actually implemented that, using Alvaro's suggestion of a flag in the Portal,
and decided that if duration is exceeded, for bind or execute, then it's likely
desirable to log the params, even if it's duplicitive. Since I've been using
log_statement=all, and not log_min_duration_statement, I don't have a strong
opinion about it.

Perhaps you're right (and perhaps I should switch to
log_min_duration_statement). I'll tentately plan to withdraw the patch.

Thanks,
Justin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2019-04-07 16:09:57 Re: query logging of prepared statements
Previous Message Adrian Klaver 2019-04-07 15:19:23 Re: pg_upgrade --jobs

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-04-07 15:40:52 Re: Speed up transaction completion faster after many relations are accessed in a transaction
Previous Message Justin Pryzby 2019-04-07 15:27:08 Re: ToDo: show size of partitioned table