From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Maxim Orlov <orlovmg(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Convert macros to static inline functions |
Date: | 2025-02-11 09:37:16 |
Message-ID: | f56eee3c-062f-44b3-9d68-fa926dd6f71c@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31.01.25 14:29, Maxim Orlov wrote:
> Great job! I've been working on the 64 XIDs patch for years, and I've
> never liked this place. On the other hand,
> as we know, inlining does not always work since it only suggests to the
> compiler to do it. After all, many of
> these calls are used in pretty "hot" places and every instruction is
> important, in my opinion. Wouldn't it be
> better to use pg_attribute_always_inline in this particular module?
>
> PFA patch. I don't use pg_attribute_always_inline for fastgetattr and
> heap_getattr because they are relatively
> large. I think it's worth leaving the possibility for debugging here.
I've done some analysis with -Winline. The reasons for inlining to fail
are:
1) The function is too large.
2) The function call is unlikely. (Usually when used in elog() arguments.)
3) The function can never be inlined because it uses setjmp(). (This is
kind of a bug on our end, I think.)
The existing uses of pg_attribute_always_inline all appear to address
reason 1.
I think my/your patch does not touch any functions near the limit size,
so it does not seem necessary.
I think if we use pg_attribute_always_inline without any evidence, then
"inline" by itself might become meaningless.
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-02-11 09:37:37 | Re: Move wal_buffers_full to WalUsage (and report it in pgss/explain) |
Previous Message | Richard Guo | 2025-02-11 09:28:47 | Re: should we have a fast-path planning for OLTP starjoins? |