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)
