Re: EXPLAIN's handling of output-a-field-or-not decisions

Hi,

On 2020-01-26 17:53:09 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I've previously wondered about adding a REGRESS option to EXPLAIN would
> > not actually be a good one, so we can move the magic into that, rather
> > than options that are also otherwise relevant.
>
> I'd be inclined to think about a GUC actually.
> force_parallel_mode = regress is sort of precedent for that,
> and we do already have the infrastructure needed to force a
> database-level GUC setting for regression databases.

Yea, a GUC could work too. What would it do exactly? Hide COSTS, TIMING,
JIT, unless explicitly turned on in the EXPLAIN? And perhaps also
"redact" a few things that we currently manually have to filter out?
And then we'd leave the implicit JIT to on, to allow users to see where
time is spent?

Or were you thinking of something different entirely?

> I can see some advantages to making it an explicit EXPLAIN option
> instead --- but unless we wanted to back-patch it, it'd be a real
> pain in the rear for back-patching regression test cases.

Hm. Would it really be harder? I'd expect that we'd end up writing tests
in master that need additional options to be usable in the back
branches. Seems we'd definitely need to backpatch the GUC?

Greetings,

Andres Freund