From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: EXPLAIN's handling of output-a-field-or-not decisions |
Date: | 2020-01-26 22:42:54 |
Message-ID: | 20200126224254.c3wvppgwh2w4u3sj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-01-26 16:54:58 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-01-26 22:49:06 | Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() |
Previous Message | Tom Lane | 2020-01-26 21:54:58 | Re: EXPLAIN's handling of output-a-field-or-not decisions |