Re: jit and explain nontext

On Thu, 15 Oct 2020 at 14:43, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> On Thu, Oct 15, 2020 at 02:23:01PM +1300, David Rowley wrote:
> > On Thu, 15 Oct 2020 at 14:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Hmm, I dunno if my opinion counts as "wisdom", but what I was arguing for
> > > there was that we should print stuff if it's potentially invoked by a
> > > run-time decision, but not if it was excluded at plan time. I'm not
> > > totally clear on whether jitting decisions are fixed by the plan tree
> > > (including its cost values) or if the executor can make different
> > > decisions in different executions of the identical plan tree.
> > > If the latter, then I agree with Justin that this is a bug.
> >
> > As far as I know, the only exception where the executor overwrites the
> > planner's decision is in nodeValuesscan.c where it turns jit off
> > because each VALUES will get evaluated just once, which would be a
> > waste of effort to JIT.
> >
> > Apart from that the choice is baked in by the planner and set in
> > PlannedStmt.jitfFlags.
>
> What about the GUCs themselves ?
>
> They can change after planning, which means a given execution of a plan might
> or might not use jit.

That's a pretty good point. If we do SET enable_sort TO off; then
cached plans are unaffected. That's not the case when someone does
SET jit TO off; as we'll check that in provider_init() during
execution. Although, switching jit back on again works differently.
If the planner saw it was off then switching it on again won't have
existing plans use it. That's slightly weird, but perhaps it was done
that way to ensure there was a hard off switch. You might want to
ensure that to ensure queries don't break if there was some problem
with LLVM libraries.

David