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
|
Список | 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 по дате отправления: