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

Le mar. 12 nov. 2024 à 16:35, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a
écrit :

> Le mar. 12 nov. 2024 à 16:21, Robert Haas <robertmhaas(at)gmail(dot)com> a
> écrit :
>
>> On Mon, Nov 11, 2024 at 3:59 PM Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>> > Agreed. Having an "EXPLAIN (ALL)" would be a great addition. I could
>> tell a customer to do an "EXPLAIN (ALL)", rather than first asking the
>> PostgreSQL release installed on the server and after that, giving the
>> correct options for EXPLAIN.
>>
>> I realize that you're probably going to hate my guts -- or hate them
>> even more than you do already -- but I doubt that a proposal to add
>> EXPLAIN (ALL) will go anywhere.
>
>
> I don't hate your guts :) and...
>
>
>> The definitional problem is that it is
>> not clear what to do with non-Boolean valued options, such as
>> SERIALIZE. People who think that we were wrong not to make SERIALIZE
>> TEXT the default in v17 will argue that EXPLAIN (ALL) should turn it
>> on; after all, the backward-compatibility argument carries no water in
>> that case. But people who do not like the behavior of SERIALIZE TEXT
>> will not be happy about that. They might directly make that argument,
>> or they might instead make the argument that ALL should do nothing
>> about a non-Boolean valued option. But that position is really quite
>> difficult to justify. Let's suppose that the current BUFFERS option,
>> which is Boolean, got replaced with BUFFERS { detailed | on | off }.
>> Well, then, by the principle that ALL only affects Boolean-valued
>> options, it's no longer included in EXPLAIN (ALL). Nobody will be
>> happy with that. Practically speaking, I think it will be very
>> difficult to get agreement on what EXPLAIN (ALL) should do, and I
>> think it is unlikely that anything will get committed no matter how
>> much time we spend arguing about it.
>>
>>
> ... I kinda agree with you. It would have been nice to have an "EXPLAIN
> (ALL)" but I completely understand the issue.
>
>
>> But I think we would get most of the same benefit from just doing what
>> David Rowley proposed and turning on EXPLAIN (BUFFERS) by default. I'd
>> suggest that we decide that, without ANALYZE, the option would not do
>> anything; that is already how TIMING works. So this would be a very
>> small patch and would probably get a lot of support from a lot of
>> people. It also wouldn't require users to change their habits or learn
>> any new syntax -- they could just keep typing EXPLAIN ANALYZE or
>> EXPLAIN ANALYZE VERBOSE and all would be well.
>>
>>
> That would be a nice enhancement.
>
>
>> And the same principle could be applied to other EXPLAIN options if
>> there is sufficient consensus. We could default to WAL ON, SERIALIZE
>> TEXT, and MEMORY ON, if we wanted to do that. However, the more we try
>> to change at once, the less likely it is that anything will happen at
>> all. For example, I personally believe that EXPLAIN (MEMORY) should be
>> ripped out of the server as both badly-named and mostly useless, so
>> I'm not going to vote in favor of turning it on by default; and I
>> wouldn't vote for enabling WAL by default because I have no experience
>> with it to suggest that it's routinely valuable and thus worth the
>> overhead. I would vote for SERIALIZE TEXT because I've seen that cause
>> gross distortion of EXPLAIN ANALYZE results on many occasions. But the
>> point is that other people will vote differently, so tying all the
>> proposals together just increases the chances of agreeing on nothing
>> at all.
>>
>>
> Agreed.
>
>
>> So to recap: everyone is free to propose whatever they like, and I am
>> not in charge here, but if you want to get something committed, the
>> proposal which I think has the highest chance of success is: propose
>> to make BUFFERS ON the default (but a noop without ANALYZE, similar to
>> how TIMING already works).
>>
>>
> Sounds like a plan.
>
>
Sure looks easy enough to do (though it still lacks doc and tests changes).
See patch attached.

--
Guillaume.