Re: Lazy JIT IR code generation to increase JIT speed with partitions

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Lazy JIT IR code generation to increase JIT speed with partitions
Дата
Msg-id 20220704202347.umiphdqxttjkfi22@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Lazy JIT IR code generation to increase JIT speed with partitions  (Luc Vlaming Hummel <luc.vlaming@servicenow.com>)
Ответы Re: Lazy JIT IR code generation to increase JIT speed with partitions  (David Geier <geidav.pg@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-07-04 06:43:00 +0000, Luc Vlaming Hummel wrote:
> Thanks for reviewing this and the interesting examples!
> 
> Wanted to give a bit of extra insight as to why I'd love to have a system that can lazily emit JIT code and hence
createsroughly a module per function:
 
> In the end I'm hoping that we can migrate to a system where we only JIT after a configurable cost has been exceeded
forthis node, as well as a configurable amount of rows has actually been processed.
 
> Reason is that this would safeguard against some problematic planning issues
> wrt JIT (node not being executed, row count being massively off).

I still don't see how it's viable to move to always doing function-by-function
emission overhead wise.

I also want to go to do JIT in the background and triggered by acutal
usage. But to me it seems a dead end to require moving to
one-function-per-module model for that.


> If this means we have to invest more in making it cheap(er) to emit modules,
> I'm all for that.

I think that's just inherently more expensive and thus a no-go.


> @Andres if there's any other things we ought to fix to make this cheap
> (enough) compared to the previous code I'd love to know your thoughts.

I'm not seeing it.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kenaniah Cerny
Дата:
Сообщение: Re: Proposal: allow database-specific role memberships
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Export log_line_prefix(); useful for emit_log_hook.