From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@postgresql.org,
        Andres Freund <andres@anarazel.de>
Subject: Re: jit and explain nontext
In-reply-to: <20201130165932.GA7242@telsasoft.com>
References: 
 <CAApHDvpPt=iN=f5gHQSCA073mp5KO46gsEZFgTWc4xbzKshb9g@mail.gmail.com>
 <3643530.1602724513@sss.pgh.pa.us>
 <CAApHDvqK2HAm-BWxgo7=7GG5xERuECwgny+Sxh3iLfXmhR_yBQ@mail.gmail.com>
 <20201015014326.GU9241@telsasoft.com>
 <CAApHDvozf41o7bUyLL42LWwAjqjRuDToeWy-S5jwR4BieM7SYA@mail.gmail.com>
 <20201017192134.GD9241@telsasoft.com>
 <a56f853c-e671-c4b1-7e0e-a1f0a18621e4@enterprisedb.com>
 <20201120161622.GI24784@telsasoft.com>
 <e5f51922-a6af-4ada-62fa-a18ca6d0b469@enterprisedb.com>
 <20201121162600.GN24784@telsasoft.com> <20201130165932.GA7242@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Mon, 30 Nov 2020 10:59:32 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1677872.1610740429.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 15 Jan 2021 14:53:49 -0500
Message-ID: <1677873.1610740429@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sat, Nov 21, 2020 at 10:26:00AM -0600, Justin Pryzby wrote:
>> On Sat, Nov 21, 2020 at 08:39:11AM +0100, Peter Eisentraut wrote:
>>> In this context, I don't see the point of this change.  If you set jit=
=3Doff
>>> explicitly, then there is no need to clutter the EXPLAIN output with a=
 bunch
>>> of zeroes about JIT.

> If there's no interest or agreement in it, we should just close it.
> I have no personal need for it, but noticed it in passing.

I dug around a bit and saw that essentially all of the JIT control
GUCs are consulted only at plan time (cf standard_planner, which
fills PlannedStmt.jitFlags based on the then-active settings).
So the only thing that really counts as a "run time decision"
here is that if you set jit =3D off between planning and execution,
or if we fail to load the JIT provider at all, then you'll get
no JITting even though the planner expected it to happen.

On balance I agree with Peter's opinion that this isn't worth
changing.  I would be for the patch if the executor had a little
more freedom of action, but as things stand there's not much
freedom there.

			regards, tom lane