Re: [PATCH] Add pg_lfind8_nonzero()
| От | Andres Freund |
|---|---|
| Тема | Re: [PATCH] Add pg_lfind8_nonzero() |
| Дата | |
| Msg-id | p4urpwkhqm2ugj254kix62y6gxal3i3qwrgq3jjtoiyvp4gvot@5nzpaquv6azq обсуждение исходный текст |
| Ответ на | [PATCH] Add pg_lfind8_nonzero() ("cca5507" <cca5507@qq.com>) |
| Ответы |
Re: [PATCH] Add pg_lfind8_nonzero()
|
| Список | pgsql-hackers |
Hi,
On 2025-12-14 21:33:00 +0800, cca5507 wrote:
> Hi hackers,
>
> I'd like to add pg_lfind8_nonzero() to optimize some code like this:
>
> ```
> for (i = 0; i < numberOfAttributes; i++)
> {
> if (isnull[i])
> {
> hasnull = true;
> break;
> }
> }
> ```
Is code like this ever actually relevant for performance? In cases where the
compiler can't also optimize the code? Unless it is a legitimate bottleneck,
adding more complicated code to optimize the case doesn't make sense.
> create extension test_patch;
> # 4 is the natts
> select test_head(4);
> select test_patch(4);
>
> Test result:
> natts: 4 head: 1984ns patch: 2094ns
> natts: 8 head: 3196ns patch: 641ns
> natts: 16 head: 4589ns patch: 752ns
> natts: 32 head: 8036ns patch: 1152ns
> natts: 64 head: 19367ns patch: 2455ns
> natts: 128 head: 33445ns patch: 4018ns
>
> Looking forward to your comments!
>
The benchmark really should show performance benefits in at least somewhat
realistic cases (i.e. real users of the functions, even if the workload is a
bit more extreme than it'd be most of the time).
Greetings,
Andres
В списке pgsql-hackers по дате отправления: