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

From Andres Freund
Subject Re: optimize lookups in snapshot [sub]xip arrays
Date
Msg-id 20220802225539.nm7bgkwvkpzgib5x@awork3.anarazel.de
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
Hi,

FWIW, I'd split the introduction of the helper and the use of it in snapmgr
into separate patches.


On 2022-08-02 15:13:01 -0700, Nathan Bossart wrote:
> diff --git a/src/include/c.h b/src/include/c.h
> index d35405f191..2c1a47bc28 100644
> --- a/src/include/c.h
> +++ b/src/include/c.h
> @@ -371,6 +371,14 @@ typedef void (*pg_funcptr_t) (void);
>  #endif
>  #endif
>  
> +/*
> + * Are SSE2 intrinsics available?
> + */
> +#if (defined(__x86_64__) || defined(_M_AMD64))
> +#include <emmintrin.h>
> +#define USE_SSE2
> +#endif
> +

It doesn't strike me as a good idea to include this in every single
translation unit in pg. That header (+dependencies) isn't small.

I'm on board with normalizing defines for SSE availability somewhere central
though.


> +/*
> + * pg_linearsearch_uint32
> + *
> + * Returns the address of the first element in 'base' that equals 'key', or
> + * NULL if no match is found.
> + */
> +#ifdef USE_SSE2
> +pg_attribute_no_sanitize_alignment()
> +#endif

What's the deal with this annotation? Needs a comment.


> +static inline uint32 *
> +pg_linearsearch_uint32(uint32 key, uint32 *base, uint32 nelem)

Hm. I suspect this could be a bit faster if we didn't search for the offset,
but just for presence in the array? Most users don't need the offset.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: [PATCH] CF app: add "Returned: Needs more interest"
Next
From: Tom Lane
Date:
Subject: Re: [PROPOSAL] new diagnostic items for the dynamic sql