From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE |
Date: | 2024-11-05 23:32:53 |
Message-ID: | CAKFQuwbLq3GWoJw-zNa43pkcfg5gh4gGQKMptQtp4qX_nQL9AQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 5, 2024 at 3:55 PM Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
wrote:
>
> 4. Making BUFFERS default behavior for EXPLAIN ANALYZE was raised several
> times, for example
> https://www.postgresql.org/message-id/flat/CANNMO++=LrJ4upoeydZhbmpd_ZgZjrTLueKSrivn6xmb=yFwQw(at)mail(dot)gmail(dot)com
> (2021) – and my understanding that it was received great support and it
> discussed in detail why it's useful, but then several attempts to implement
> it were not accomplished because of tech difficulties (as I remember,
> problem with broken tests and how to fix that).
>
The main premise here is that explain should include buffers by default,
and to do so we are willing to inconvenience testers who do not want buffer
data in their test plans to have to modify their tests to explicitly
exclude buffers. We'll have to eat our own dog food here and go and add
"buffers off" throughout our code base to make this happen. I personally
feel that we should accept a patch that does so. The benefits to the many
outweigh the one-time inconveniencing of the few. Especially if limited to
explain analyze.
> 5. EXPLAIN ALL proposed in
> https://www.postgresql.org/message-id/flat/080FE841-E38D-42A9-AD6D-48CABED163C9(at)endpoint(dot)com
> (2016) – I think it's actually a good idea originally, but didn't survive
> questions of mutually exclusive options and non-binary options, and then
> discussion stopped after pivoting in direction of GUC.
>
If the desire is to make the current keyword VERBOSE behave like the
proposed ALL keyword then one must first get a version of ALL accepted,
then argue for repurposing VERBOSE instead of adding the new keyword. But
at this point I really do not see extending verbose to mean more than "add
more comments and context labels". Verbose has never meant to include
everything and getting buy-in to change that seems highly unlikely.
In short, neither change is deemed unwanted, and indeed has desire. It's a
matter of learning from the previous attempt to increase the odds of
getting something committed.
I wouldn't advise expending effort or political capital on the parentheses
topic at this point.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2024-11-05 23:33:28 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | David Rowley | 2024-11-05 23:16:33 | Re: define pg_structiszero(addr, s, r) |