Re: jit and explain nontext - Mailing list pgsql-hackers

From Tom Lane
Subject Re: jit and explain nontext
Date
Msg-id 1677873.1610740429@sss.pgh.pa.us
Whole thread Raw
In response to Re: jit and explain nontext  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: jit and explain nontext  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
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=off
>>> 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 = 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



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [patch] [doc] Further note required activity aspect of automatic checkpoint and archving
Next
From: Andres Freund
Date:
Subject: Re: Printing backtrace of postgres processes