Re: Change GUC hashtable to use simplehash? - Mailing list pgsql-hackers

From John Naylor
Subject Re: Change GUC hashtable to use simplehash?
Date
Msg-id CANWCAZaZ2QXvhWx7DS=yngOYuHGvea+-MsYqwoSWK2jCv3M8Dw@mail.gmail.com
Whole thread Raw
In response to Re: Change GUC hashtable to use simplehash?  (John Naylor <johncnaylorls@gmail.com>)
List pgsql-hackers
On Wed, Nov 29, 2023 at 8:31 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> Attached is a rough start with Andres's earlier ideas, to get
> something concrete out there.

While looking at the assembly out of curiosity, I found a couple bugs
in the split API that I've fixed locally.

I think the path forward is:

- performance measurements with both byte-at-a-time and
word-at-a-time, once I make sure they're fixed
- based on the above decide which one is best for guc_name_hash
- clean up hash function implementation
- test with with a new guc_name_compare (using what we learned from my
guc_name_eq) and see how well we do with keeping dynahash vs.
simplehash

Separately, for string_hash:

- run SMHasher and see about reincorporating length in the
calculation. v5 should be a clear improvement in collision behavior
over the current guc_name_hash, but we need to make sure it's at least
as good as hash_bytes, and ideally not lose anything compared to
standard fast_hash.



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Commitfest 2023-11 is almost over
Next
From: Peter Eisentraut
Date:
Subject: Re: Remove unnecessary includes of system headers in header files