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 16192.1580075698@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  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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?

>> Another debatable question is whether to print anything in non-JIT
>> builds.

> Hm. I don't think I have an opinion on this. I can see an argument
> either way.

After a bit more thought I'm leaning to "print nothing", since as you say
tools would have to cope with that anyway if they want to work with old
releases.  Also, while it's not that hard to print dummy data for JIT
even in a non-JIT build, I can imagine some future feature where it
*would* be hard.  So setting a precedent that we must provide dummy
output for unimplemented features could come back to bite us.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: EXPLAIN's handling of output-a-field-or-not decisions
Next
From: Andres Freund
Date:
Subject: Re: EXPLAIN's handling of output-a-field-or-not decisions