Horton

Re: Change GUC hashtable to use simplehash?

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2024-01-19T16:54:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Silence warning in older versions of Valgrind

  2. Revert "Speed up tail processing when hashing aligned C strings, take two"

  3. Speed up tail processing when hashing aligned C strings, take two

  4. Teach fasthash_accum to use platform endianness for bytewise loads

  5. Add macro to disable address safety instrumentation

  6. Convert uses of hash_string_pointer to fasthash equivalent

  7. Speed up tail processing when hashing aligned C strings

  8. Add helper functions for dshash tables with string keys.

  9. Fix warnings in cpluspluscheck

  10. Further cosmetic review of hashfn_unstable.h

  11. Simplify initialization of incremental hash state

  12. Add optimized C string hashing

  13. Add inline incremental hash functions for in-memory use

  14. Make all Perl warnings fatal

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)