| 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
| 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 |