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

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

In response to

Responses

Browse pgsql-hackers by date

  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