Re: jit and explain nontext
От
Andres Freund
Тема
Re: jit and explain nontext
Дата
Msg-id
20201015230018.474rvtfziduzzzfz@alap3.anarazel.de
Ответ на
Re: jit and explain nontext (David Rowley)
Список
Дерево обсуждения
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 по дате отправления
От: Bruce Momjian
Дата: