From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Luc Vlaming Hummel <luc(dot)vlaming(at)servicenow(dot)com> |
Cc: | David Geier <geidav(dot)pg(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lazy JIT IR code generation to increase JIT speed with partitions |
Date: | 2022-07-04 20:23:47 |
Message-ID: | 20220704202347.umiphdqxttjkfi22@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 creates roughly 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 for this 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2022-07-04 20:24:36 | Re: Export log_line_prefix(); useful for emit_log_hook. |
Previous Message | Kenaniah Cerny | 2022-07-04 20:17:00 | Re: Proposal: allow database-specific role memberships |