Re: Change GUC hashtable to use simplehash?

On 19/01/2024 09:27, John Naylor wrote:
> Pushed that way, thanks! After fixing another typo in big endian
> builds, an s390x member reported green, so I think that aspect is
> working now. I'll come back to follow-up topics shortly.

Thanks! I started to look at how to use this, and I have some questions. 
I'd like to replace this murmurhash ussage in resowner.c with this:

>     /*
>      * Most resource kinds store a pointer in 'value', and pointers are unique
>      * all on their own.  But some resources store plain integers (Files and
>      * Buffers as of this writing), so we want to incorporate the 'kind' in
>      * the hash too, otherwise those resources will collide a lot.  But
>      * because there are only a few resource kinds like that - and only a few
>      * resource kinds to begin with - we don't need to work too hard to mix
>      * 'kind' into the hash.  Just add it with hash_combine(), it perturbs the
>      * result enough for our purposes.
>      */
> #if SIZEOF_DATUM == 8
>     return hash_combine64(murmurhash64((uint64) value), (uint64) kind);
> #else
>     return hash_combine(murmurhash32((uint32) value), (uint32) kind);
> #endif

The straightforward replacement would be:

     fasthash_state hs;

     fasthash_init(&hs, sizeof(Datum), 0);
     fasthash_accum(&hs, (char *) &kind, sizeof(ResourceOwnerDesc *));
     fasthash_accum(&hs, (char *) &value, sizeof(Datum));
     return fasthash_final32(&hs, 0);

But I wonder if it would be OK to abuse the 'seed' and 'tweak' 
parameters to the init and final functions instead, like this:

     fasthash_state hs;

     fasthash_init(&hs, sizeof(Datum), (uint64) kind);
     return fasthash_final32(&hs, (uint64) value);

I couldn't find any guidance on what properties the 'seed' and 'tweak' 
have, compared to just accumulating the values with accum. Anyone know?

-- 
Heikki Linnakangas
Neon (https://neon.tech)