Re: Change GUC hashtable to use simplehash?

On Sat, Dec 9, 2023 at 3:32 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Wed, 2023-11-29 at 20:31 +0700, John Naylor wrote:
> > Attached is a rough start with Andres's earlier ideas, to get
> > something concrete out there.
>
> The implementation of string hash in 0004 forgot to increment 'buf'.

Yeah, that was one of the bugs I mentioned. In v6, I fixed it so we
get the right answer.

0001 pure copy of fasthash upstream
0002 keeps the originals for validation, and then re-implements them
using the new incremental interfaces
0003 adds UINT64CONST. After writing this I saw that murmur64 didn't
have UINT64CONST (and obviously no buildfarm member complained), so
probably not needed.
0004 Assert that the original and incrementalized versions give the
same answer. This requires the length to be known up front.
0005 Demo with pgstat_hash_hash_key, which currently runs 3 finalizers
joined with hash_combine. Might shave a few cycles.
0006 Add bytewise interface for C strings.

0007 Use it in guc_name_hash
0008 Teach guc_name_cmp to case fold lazily

I'll test these two and see if there's a detectable difference. Then
each of these:

0009 Jeff's conversion to simplehash
0010 Use an inline equality function for guc nam. hash
0011/12 An experiment to push case-folding down inside fasthash. It's
not great looking, but I'm curious if it makes a difference.

0013 Get rid of strlen in dynahash with default string hashing. I'll
hold on to this and start a new thread, because it's off-topic and has
some open questions.

I haven't tested yet, but I want to see what CI thinks.

> I tested using the new hash function APIs for my search path cache, and
> there's a significant speedup for cases not benefiting from a86c61c9ee.
> It's enough that we almost don't need a86c61c9ee. So a definite +1 to
> the new APIs.

Do you have a new test?