Re: jit and explain nontext

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jit and explain nontext
Date: 2020-10-15 23:00:18
Message-ID: 20201015230018.474rvtfziduzzzfz@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-10-15 14:51:38 +1300, David Rowley wrote:
> That's a pretty good point. If we do SET enable_sort TO off; then
> cached plans are unaffected.

In contrast to that we do however use the current work_mem for
execution, I believe. Which could be fairly nasty, if a plan was made
for a huge work_mem, for example.

> 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.

It was motivated by not wanting to just enable JIT for queries that were
prepared within something like SET LOCAL jit=off;PREPARE; RESET
jit;. I'm open to revising it, but that's where it's coming from.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-10-15 23:35:30 Re: pg_upgrade: fail early if a tablespace dir already exists for new cluster version
Previous Message Andres Freund 2020-10-15 22:37:01 Re: gs_group_1 crashing on 13beta2/s390x