Re: LLVMJIT: introduce force-inlined functions

From: "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
To: "Pierre Ducroquet" <p(dot)psql(at)pinaraf(dot)info>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LLVMJIT: introduce force-inlined functions
Date: 2026-03-23 21:03:35
Message-ID: DHAGSIU6JJAO.33OWXGEGA9NSO@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, I just found this thread when searching another thread, thanks for
working on this!

On Mon Jan 26, 2026 at 2:23 PM -03, Pierre Ducroquet wrote:
> Hi
>
> A bunch of functions are the most used in queries. The llvmjit
> inlining system (tries to) get rid of the overhead of calling any
> function, but this is triggered only when the cost is above
> jit_inline_above_cost. There is thus a nice performance boost to have
> by choosing to "manually" inline a few specific PostgreSQL functions.
> In this first patch, I've chosen to inline int4eq, int8eq and most
> date comparison functions. They are definitely small, the generated
> code is not bigger when inlining them (surprisingly, on amd64 the code
> is even smaller) and are unlikely to ever change so there won't be any
> maintenance burden here. On my AMD 3900XT system, this gives me a 3 to
> 5% performance improvement when running 1M dateeq calls. I will likely
> submit a second patch version later with more functions implemented,
> but I thought this was an interesting first result worth discussing
> already.
>

This seems interesting. Do you have the planning time comparison with
and without this patch? Wondering if it increase with this inline pass.

Do you still intend to send a v2 of this patch? The current set of
functions is a good starting point IMHO, what others do you have in
mind?

(a pgindent is welcome for easier review)

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-03-23 21:21:31 Re: unclear OAuth error message
Previous Message Nathan Bossart 2026-03-23 21:01:22 Re: another autovacuum scheduling thread