Re: [PATCH] Add pg_lfind8_nonzero()

From: Andres Freund <andres(at)anarazel(dot)de>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Add pg_lfind8_nonzero()
Date: 2025-12-14 15:27:06
Message-ID: p4urpwkhqm2ugj254kix62y6gxal3i3qwrgq3jjtoiyvp4gvot@5nzpaquv6azq
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2025-12-14 15:46:30 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Andres Freund 2025-12-14 15:19:21 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY