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