Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Michael Christofides <michael(at)pgmustard(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE
Date: 2025-05-30 11:55:20
Message-ID: CAApHDvpqjJqXq2eBXzCqeoAyVANnVg7brrkRiQMENBo8tf44_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 29 May 2025 at 16:28, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> I agree with changing the default value of auto_explain.log_buffers to true.
> I think that users who know EXPLAIN ANALYZE includes buffers info in
> the result by default since v18 would expect the buffer info also to
> be included in auto_explain output as long as log_analyze is enabled.
> So setting log_buffers to true by default would be less confusing.

I feel somewhat responsible to answer here since I committed the
EXPLAIN ANALYZE change. I'm still neutral.

By my count, those who think we should change log_buffers to true are:
Robert [1], Michael Christofides [2], Fujii [3].

I expect arguments against might be related to log space or
performance. I did a quick test to try to get an idea of what we're
looking at. I'm unsure how realistic it would be that someone would
use auto_explain to log this many plans, but there is a bit of a
performance overhead to enabling log_buffers. Full results attached,
but here's the summary after ignoring the first result of each and
taking the average of the remaining 9 runs of each. I deleted the log
file between each test.

log_min_duration = 0, log_buffers = off: 11231 tps
log_min_duration = 0, log_buffers = on: 11106 tps
log_min_duration = -1 (off): 13297 tps

So it is possible to measure it, at least.

David

[1] https://www.postgresql.org/message-id/CA%2BTgmoZO2HtDGHf7K4rmNdfUGuS%3DngsPgwrH%3DJdyF6Okcnzfkw%40mail.gmail.com
[2] https://www.postgresql.org/message-id/flat/a6206e08-0607-42fe-91fd-e7bd45fa235a%40oss.nttdata.com#47cd88d71be28287d3e29c833d98eb48
[3] https://www.postgresql.org/message-id/a6206e08-0607-42fe-91fd-e7bd45fa235a%40oss.nttdata.com

Attachment Content-Type Size
log_buffers_overhead.txt text/plain 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-05-30 12:02:41 Re: Optimize shared LWLock acquisition for high-core-count systems
Previous Message Shaik Mohammad Mujeeb 2025-05-30 11:34:10 Re: Add comment explaining why queryid is int64 in pg_stat_statements