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

From Andres Freund
Subject Re: EXPLAIN's handling of output-a-field-or-not decisions
Date
Msg-id 20200126224254.c3wvppgwh2w4u3sj@alap3.anarazel.de
Whole thread Raw
In response to Re: EXPLAIN's handling of output-a-field-or-not decisions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EXPLAIN's handling of output-a-field-or-not decisions
List pgsql-hackers
Hi,

On 2020-01-26 16:54:58 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2020-01-26 15:13:49 -0500, Tom Lane wrote:
> >> The other offender is the JIT stuff: it prints if COSTS is on and
> >> there's some JIT activity to report, and otherwise you get nothing.
> >> This is OK for text mode but it's bogus for the other formats.
> >> Since we just rearranged EXPLAIN's JIT output anyway, now seems like
> >> a good time to fix it.
> 
> > No objection. I think the current choice really is just about hiding JIT
> > information in the cases where we display explain output in the
> > tests. That output can't change depending on the build environment and
> > settings (it's e.g. hugely useful to force all queries to be JITed for
> > coverage).
> 
> Right, but then ...
> 
> > One concern I do have is that I think we need the overall time for JIT
> > to be displayed regardless of the JIT option.
> 
> ... 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.

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: EXPLAIN's handling of output-a-field-or-not decisions
Next
From: Peter Geoghegan
Date:
Subject: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()