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)