Обсуждение: LLVMJIT: introduce force-inlined functions
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
Вложения
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