Horton

Re: Change GUC hashtable to use simplehash?

Anton A. Melnikov <a.melnikov@postgrespro.ru>

View thread
From: "Anton A. Melnikov" <a.melnikov@postgrespro.ru>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-23T01:52: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

Hi!

On 22.01.2025 11:37, John Naylor wrote:
> On Fri, Jan 17, 2025 at 4:50 PM John Naylor <johncnaylorls@gmail.com> wrote:
>>
>> It would be a lot more readable to revert the offending commit
>> instead, since its predecessor had a much simpler bytewise loop.

Agreed that reverting seems as a preferable way, and here's why.
I found that this valgrind error during initdb first appeared
after 0aba25544. At the previous e97b672c88 where there is no error
i did a small experiment on my laptop.
With -O2 compilation from src/backend/catalog/namespace.с:369
that really executes inlined spcachekey_hash()
to src/backend/catalog/namespace.с:369
123 asm instructions are executed when hashing the string "pg_catalog".

In the master at 630f9a43 the spcachekey_hash() is not inlined
and asm call <spcachekey_hash> executes 204 asm inctructions
at the same conditions. HAVE__BUILTIN_CTZ is defined on my pc
so finding the first non-zero rightmost bit requires
the only asm command.

With patch v2-0001-Add-valgrind-safe-code the same will take 216
asm instructions.

Of cause, if the common average length of a hashed string is known,
can be performed experiments that better correspond to reality.
But, it seems to me, there shouldn't be any considerably
large strings here, so the general trend is clear.
Please correct me if I'm wrong.


With the best regards,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company