Re: jit and explain nontext

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

Justin Pryzby <pryzby(at)telsasoft(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-01-15 20:10:11 Re: Printing backtrace of postgres processes
Previous Message David G. Johnston 2021-01-15 19:50:43 Re: [patch] [doc] Further note required activity aspect of automatic checkpoint and archving