Re: jit and explain nontext

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: jit and explain nontext
Date: 2020-11-21 16:26:00
Message-ID: 20201121162600.GN24784@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 21, 2020 at 08:39:11AM +0100, Peter Eisentraut wrote:
> On 2020-11-20 17:16, Justin Pryzby wrote:
> > It matters if it was planned with jit but executed without jit.
> >
> > postgres=# DEALLOCATE p; SET jit=on; SET jit_above_cost=0; prepare p as select from generate_series(1,9); explain(format yaml) execute p; SET jit=off; explain(format yaml) execute p;
> >
> > Patched shows this for both explains:
> > JIT: +
> > Functions: 3 +
> >
> > Unpatched shows only in the first case.
>
> In this context, I don't see the point of this change. If you set jit=off
> explicitly, then there is no need to clutter the EXPLAIN output with a bunch
> of zeroes about JIT.

I think the idea is that someone should be able to parse the YAML/XML/other
output by writing something like a['JIT']['Functions'] rather than something
like a.get('JIT',{}).get('Functions',0)

The standard seems to be that parameters that can change during execution
should change the *values* in the non-text output, but the *keys* should not
disappear just because (for example) parallel workers weren't available, or
someone (else) turned off jit. We had discussion about this earlier in the
year:
https://www.postgresql.org/message-id/20200728033622.GC20393@telsasoft.com

(Since it's machine-readable output, Key: 0 is Consistency and Completeness,
not Clutter.)

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-21 18:07:07 Re: Connection using ODBC and SSL
Previous Message Pavel Stehule 2020-11-21 15:27:09 Re: Different results between PostgreSQL and Oracle for "for update" statement