Re: Change GUC hashtable to use simplehash?

On Thu, Jan 4, 2024 at 10:01 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> I still cannot git apply your patch cleanly. in

I don't know why you're using that -- the git apply man page even says

"Use git-am(1) to create commits from patches generated by
git-format-patch(1) and/or received by email."

Or, if that fails, use "patch".

> http://cfbot.cputube.org/ i cannot find your patch.
> ( so, it might be that I test based on incomplete information).
> but only hashfn_unstable.h influences bench_hash/bench_hash.c.
>
> so I attached the whole patch that I had git applied, that is the
> changes i applied for the following tests.

Well, aside from the added text-editor detritus, it looks like this
has everything except v11-0008, without which I still get improvement
for the pgstat hash.

> Model name: Intel(R) Core(TM) i5-14600K

> The following is tested with another machine, also listed machine spec below.
> I tested 3 times, the results is very similar as following:
> select * from bench_cstring_hash_aligned(100000); 4705.686 ms
> select * from bench_cstring_hash_unaligned(100000); 6835.753 ms
> select * from bench_pgstat_hash(100000); 2678.978 ms
> select * from bench_pgstat_hash_fh(100000); 6199.017 ms
> select * from bench_string_hash(100000); 847.699 ms

I was fully prepared to believe something like 32-bit Arm would have
difficulty with 64-bit shifts/multiplies etc., but this makes no sense
at all. In this test, on my machine, HEAD's pgstat_hash is 3x faster
than HEAD's "strlen + hash_bytes", but for you it's 3x slower. To
improve reproducibility, I've added the .sql files and a bench script
to v13. I invite you to run bench_hash.sh and see if that changes
anything.

v13 also
- adds an assert that aligned and unaligned C string calculations give
the same result
- properly mixes roleid in the namespace hash, since it's now
convenient to do so (0005 is an alternate method)
- removes the broken makefile from the benchmark (not for commit anyway)