Horton

Re: Change GUC hashtable to use simplehash?

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Anton A. Melnikov" <a.melnikov@postgrespro.ru>
Cc: John Naylor <johncnaylorls@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Ants Aasma <ants.aasma@cybertec.at>, Heikki Linnakangas <hlinnaka@iki.fi>, Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>, Andres Freund <andres@anarazel.de>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2025-01-16T01:36:01Z
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

"Anton A. Melnikov" <a.melnikov@postgrespro.ru> writes:
> Seems it is possible to exclude much less code from checking
> under valgrind and get the same result by replacing the only
> function call pg_rightmost_one_pos64() with a valgrind-safe
> code. See the attached patch, please.

There is no place anywhere in our code base where we hide unsafe
code from valgrind rather than fixing said code.  This does not
seem like a place to start such an ugly practice.  Performance
does not trump everything else.

I'd be inclined to just remove the pg_rightmost_one_pos64 call
in favor of the other coding you suggest.

			regards, tom lane