Обсуждение: LLVMJIT: introduce force-inlined functions

Поиск
Список
Период
Сортировка

LLVMJIT: introduce force-inlined functions

От
Pierre Ducroquet
Дата:
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.

Regards
Вложения

Re: LLVMJIT: introduce force-inlined functions

От
"Matheus Alcantara"
Дата:
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