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

From John Naylor
Subject Re: optimize lookups in snapshot [sub]xip arrays
Date
Msg-id CAFBsxsH51bBtyr3rf13x7YMNkFfuzZPSQxxbfUepBj8m4=ck=Q@mail.gmail.com
Whole thread Raw
In response to Re: optimize lookups in snapshot [sub]xip arrays  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: optimize lookups in snapshot [sub]xip arrays
List pgsql-hackers

On Thu, Aug 4, 2022 at 3:25 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> Here is a new patch set without the annotation.

Were you considering adding the new function to simd.h now that that's committed? It's a bit up in the air what should go in there, but this new function is low-level and generic enough to be a candidate...

I wonder if the "pg_" prefix is appropriate here, as that is most often used for things that hide specific details *and* where the base name would clash, like OS calls or C library functions. I'm not quite sure where the line is drawn, but I mean that "linearsearch" is a generic algorithm and not a specific API we are implementing, if that makes sense.

The suffix "_uint32" might be more succinct as "32" (cf pg_bswap32(), pg_popcount32, etc). We'll likely want to search bytes sometime, so something to keep in mind as far as naming ("_int" vs "_byte"?).

I'm not a fan of "its" as a variable name, and I'm curious what it's intended to convey.

All the __m128i vars could technically be declared const, although I think it doesn't matter -- it's just a hint to the reader.

Out of curiosity do we know how much we get by loading four registers rather than two?
--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: A proposal for shared memory based backup infrastructure
Next
From: Amit Langote
Date:
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size