Re: jit and explain nontext

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: jit and explain nontext
Дата
Msg-id
20201015230018.474rvtfziduzzzfz@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
jit and explain nontext Justin Pryzby <pryzby@telsasoft.com>
Re: jit and explain nontext David Rowley <dgrowleyml@gmail.com>
Re: jit and explain nontext Tom Lane <tgl@sss.pgh.pa.us>
Re: jit and explain nontext David Rowley <dgrowleyml@gmail.com>
Re: jit and explain nontext Justin Pryzby <pryzby@telsasoft.com>
Re: jit and explain nontext David Rowley <dgrowleyml@gmail.com>
Re: jit and explain nontext Andres Freund <andres@anarazel.de>
Re: jit and explain nontext Justin Pryzby <pryzby@telsasoft.com>
Re: jit and explain nontext Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: jit and explain nontext David Rowley <dgrowleyml@gmail.com>
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


В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата:
От: Bruce Momjian
Дата:
FAQ