Horton

Re: Change GUC hashtable to use simplehash?

John Naylor <johncnaylorls@gmail.com>

View thread
From: John Naylor <johncnaylorls@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2023-12-04T05:12:06Z
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 Mon, Dec 4, 2023 at 4:16 AM Jeff Davis <pgsql@j-davis.com> wrote:
> I'm trying to follow the distinctions you're making between dynahash
> and simplehash -- are you saying it's easier to do incremental hashing
> with dynahash, and if so, why?

That's a good thing to clear up. This thread has taken simplehash as a
starting point from the very beginning. It initially showed no
improvement, and then we identified problems with the hashing and
equality computations. The latter seem like independently commitable
improvements, so I'm curious if they help on their own, even if we
still need to switch to simplehash as a last step to meet your
performance goals.

> If I understood what Andres was saying, the exposed hash state would be
> useful for writing a hash function like guc_name_hash().

From my point of view, it would at least be useful for C-strings,
where we don't have the length available up front.

Aside from that, we have multiple places that compute full 32-bit
hashes on multiple individual values, and then combine them with
various ad-hoc ways. It could be worth exploring whether an
incremental interface would be better in those places on a
case-by-case basis.

(If Andres had something else in mind, I'll let him address that.)

> But whether we
> use simplehash or dynahash is a separate question, right?

Right, the table implementation should treat the hash function as a
black box. Think of the incremental API as lower-level building blocks
for building hash functions.

> Also, while the |= 0x20 is a nice trick for lowercasing, did we decide
> that it's better than my approach in patch 0004 here:
>
> https://www.postgresql.org/message-id/27a7a289d5b8f42e1b1e79b1bcaeef3a40583bd2.camel@j-davis.com
>
> which optimizes exact hits (most GUC names are already folded) before
> trying case folding?

Note there were two aspects there: hashing and equality. I demonstrated in

https://www.postgresql.org/message-id/CANWCAZbQ30O9j-bEZ_1zVCyKPpSjwbE4u19cSDDBJ%3DTYrHvPig%40mail.gmail.com

... in v4-0003 that the equality function can be optimized for
already-folded names (and in fact measured almost equally) using way,
way, way less code.