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
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 |
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 |