Re: New EXPLAIN option: ALL - Mailing list pgsql-hackers

From Andres Freund
Subject Re: New EXPLAIN option: ALL
Date
Msg-id 20190515175806.qciblz6rhi4rzu6y@alap3.anarazel.de
Whole thread Raw
In response to Re: New EXPLAIN option: ALL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New EXPLAIN option: ALL  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea.  It seemed like a great
> idea at the time, but it's going to confuse people not just Bison.

I'm not particularly invested in the idea of renaming ANALYZE - but I
think we might be able to come up with something less ambiguous than
EXECUTE. Even EXECUTION might be better.


> So ... never mind that suggestion.  Can we get anywhere with the
> rest of it?

Yes, please. I still think getting rid of

    if (es->buffers && !es->analyze)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("EXPLAIN option BUFFERS requires ANALYZE")));
and
    /* check that timing is used with EXPLAIN ANALYZE */
    if (es->timing && !es->analyze)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("EXPLAIN option TIMING requires ANALYZE")));

and then changing the default for BUFFERs would be good. I assume they'd
still only apply to query execution.

Althouh, in the case of BUFFERS, I more than once wished we'd track the
plan-time stats for buffers as well. But that's a significantly more
complicated change.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New EXPLAIN option: ALL
Next
From: Alvaro Herrera
Date:
Subject: more message fixes