Re: optimize lookups in snapshot [sub]xip arrays
| От | John Naylor |
|---|---|
| Тема | Re: optimize lookups in snapshot [sub]xip arrays |
| Дата | |
| Msg-id | CAFBsxsH51bBtyr3rf13x7YMNkFfuzZPSQxxbfUepBj8m4=ck=Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: optimize lookups in snapshot [sub]xip arrays (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: optimize lookups in snapshot [sub]xip arrays
|
| Список | 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"?).
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
--
John Naylor
EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: