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>, Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2023-11-29T14:59:37Z
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 29/11/2023 15:31, John Naylor wrote:
> However, I did find a couple hash functions that are much simpler to
> adapt to a bytewise interface, pass SMHasher, and are decently fast on
> short inputs:
> 
> - fast-hash, MIT licensed, and apparently has some use in software [1]
> - MX3, CC0 license (looking around, seems controversial for a code
> license, so didn't go further). [2] Seems to be a for-fun project, but
> the accompanying articles are very informative on how to develop these
> things.
> 
> After wacking fast-hash around, it doesn't really resemble the
> original much, and if for some reason we went as far as switching out
> the mixing/final functions, it may as well be called completely
> original work. I thought it best to start with something whose mixing
> behavior passes SMHasher, and hopefully preserve that property.

I didn't understand what you meant by the above. Did you wack around 
fast-hash, or who did? Who switched mixing/final functions; compared to 
what? The version you have in the patch matches the implementation in 
smhasher, did you mean that the smhasher author changed it compared to 
the original?

In any case, +1 on the implementation you had in the patch at a quick 
glance.

Let's also replace the partial murmurhash implementations we have in 
hashfn.h with this. It's a very similar algorithm, and we don't need two.

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