Re: EXPLAIN's handling of output-a-field-or-not decisions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: EXPLAIN's handling of output-a-field-or-not decisions
Date
Msg-id 18494.1580079189@sss.pgh.pa.us
Whole thread Raw
In response to Re: EXPLAIN's handling of output-a-field-or-not decisions  (Andres Freund <andres@anarazel.de>)
Responses Re: EXPLAIN's handling of output-a-field-or-not decisions
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-01-26 16:54:58 -0500, Tom Lane wrote:
>> ... how are you going to square that desire with not breaking the
>> regression tests?

> Well, that's how we arrived at turning off JIT information when COSTS
> OFF, because that's already something all the EXPLAINs in the regression
> tests have to do. I do not want to regress from the current state, with
> regard to both regression tests, and seeing at least a top-line time in
> the normal EXPLAIN ANALYZE cases.

Right, but that's still just a hack.

> 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.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel leader process info in EXPLAIN
Next
From: Tom Lane
Date:
Subject: Re: Duplicate Workers entries in some EXPLAIN plans