Re: optimize lookups in snapshot [sub]xip arrays - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: optimize lookups in snapshot [sub]xip arrays
Date
Msg-id 20220805202510.GA1208450@nathanxps13
Whole thread Raw
In response to Re: optimize lookups in snapshot [sub]xip arrays  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: optimize lookups in snapshot [sub]xip arrays
List pgsql-hackers
On Fri, Aug 05, 2022 at 11:02:15AM +0700, John Naylor wrote:
> That is a good point. Maybe potential helpers in simd.h should only deal
> specifically with vector registers, with it's users providing C fallbacks.
> I don't have any good ideas of where to put the new function, though.

I moved it to src/include/port for now since that's where files like
pg_bswap.h live.

> Hmm, I didn't know about those. lfind() is similar enough that it would
> make sense to have pg_lfind32() etc in src/include/port/pg_lsearch.h, at
> least for the v4 version that returns the pointer. We already declare
> bsearch_arg() in src/include/port.h and that's another kind of array
> search. Returning bool is different enough to have a different name.
> pg_lfind32_ispresent()?  *_noptr()? Meh.
> 
> Having said all that, the man page under BUGS [1] says "The naming is
> unfortunate."

I went ahead and renamed it to pg_lfind32() and switched it back to
returning the pointer.  That felt the cleanest from the naming perspective,
but as Andres noted, it might not be as fast as just looking for the
presence of the element.  I modified my small testing program to perform
many searches on small arrays, and I wasn't able to identify any impact, so
perhaps thіs is good enough.

Thoughts?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BTMaxItemSize seems to be subtly incorrect
Next
From: Alvaro Herrera
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)