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