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

Hi,

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

We did discuss adding a JIT option in 11, but it wasn't clear it'd be
useful at that time (hence the "Might want to separate that out from
COSTS at a later stage." comment ExplainOnePlan).

I'm not really bothered by entire sections that a re optional in the
other formats, tbh. Especially when they're configurable, more recent
and/or dependent on build options - tools are going to have to deal with
being absent anyway, and that's usually just about no code.

> I think we might as well go a little further and invent an explicit
> JIT option for EXPLAIN, filling in the feature that Andres didn't
> bother with originally.

Yea, I've introduced that in slightly different form in the thread I
referenced yesterday too. See 0004 in
https://www.postgresql.org/message-id/20191029000229.fkjmuld3g7f2jq7i%40alap3.anarazel.de
although it was about adding additional details, rather than showing the
"basic" information.

I'd probably want to make JIT a tristate (off, on, details), instead of
a boolean, but that's details. And can be changed later.

> What's not entirely clear to me is whether to try to preserve the
> current behavior by making it track COSTS if not explicitly
> specified.

> I'd rather decouple that and say "you must write EXPLAIN (JIT [ON]) if
> you want JIT info"; but maybe people will argue that it's already too
> late to change this?

I don't think "too late" is a concern, I don't think there's much of a
"reliance" interest here. Especially not after whacking things around
already.

One concern I do have is that I think we need the overall time for JIT
to be displayed regardless of the JIT option. Otherwise it's going to be
much harder to diagnose cases where some person reports an issue with
executor startup being slow, because of JIT overhead. I think we
shouldn't require users to guess that that's where they should
look. That need, combined with wanting the regression test output to
keep stable, is really what lead to tying the jit information to COSTS.

I guess we could make it so that JIT is inferred based on COSTS, unless
explicitly present. A bit automagical, but ...

> Another debatable question is whether to print anything in non-JIT
> builds. We could, with a little bit of pain, print a lot of zeroes
> and "falses". If we stick with the current behavior of omitting
> the JIT fields entirely, then that's extending the existing policy
> to say that configuration options are also allowed to affect the
> set of fields that are printed. Given that we allow GUCs to affect
> that set (cf track_io_timing), maybe this is okay; but it does seem
> like it's weakening the promise of a well-defined data schema for
> EXPLAIN output.

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

Greetings,

Andres Freund