Re: Change GUC hashtable to use simplehash?

John Naylor <johncnaylorls@gmail.com>

From: John Naylor <johncnaylorls@gmail.com>

To: Ants Aasma <ants.aasma@cybertec.at>

Cc: Jeff Davis <pgsql@j-davis.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org

Date: 2024-02-02T09:21: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 →

Silence warning in older versions of Valgrind
- fde7c0164ea2 17.5 landed
- 0600d276d485 18.0 landed
Revert "Speed up tail processing when hashing aligned C strings, take two"
- 6555fe197914 17.3 landed
- 235328ee4ae4 18.0 landed
Speed up tail processing when hashing aligned C strings, take two
- a365d9e2e8c1 17.0 landed
Teach fasthash_accum to use platform endianness for bytewise loads
- 0c25fee35903 17.0 landed
Add macro to disable address safety instrumentation
- db17594ad73a 17.0 landed
Convert uses of hash_string_pointer to fasthash equivalent
- f956ecd0353b 17.0 landed
Speed up tail processing when hashing aligned C strings
- 07f0f6abfc7f 17.0 landed
Add helper functions for dshash tables with string keys.
- 42a1de3013ea 17.0 cited
Fix warnings in cpluspluscheck
- 257998508672 17.0 landed
Further cosmetic review of hashfn_unstable.h
- b83033c3cff5 17.0 landed
Simplify initialization of incremental hash state
- 9ed3ee5001b6 17.0 landed
Add optimized C string hashing
- 0aba2554409e 17.0 landed
Add inline incremental hash functions for in-memory use
- e97b672c88f6 17.0 landed
Make all Perl warnings fatal
- c5385929593d 17.0 cited

Attachments

v17-0002-Shorten-dependency-chain-for-computing-hash-mask.patch (text/x-patch) patch v17-0002
v17-0001-Speed-up-last-iteration-of-aligned-fasthash.patch (text/x-patch) patch v17-0001

On Tue, Jan 30, 2024 at 7:51 PM Ants Aasma <ants.aasma@cybertec.at> wrote:
>
> It didn't calculate the same result because the if (mask) condition
> was incorrect. Changed it to if (chunk & 0xFF) and removed the right
> shift from the mask.

Yes, you're quite right.

> It seems to be half a nanosecond faster, but as I
> don't have a machine set up for microbenchmarking it's quite close to
> measurement noise.

With my "throughput-ush" test, they look good:

pgbench -n -T 20 -f bench_cstr_aligned.sql -M prepared | grep latency

master:
latency average = 490.722 ms

(Ants Aantsma) v-17 0001:
latency average = 385.263 ms

v17 0001+0002:
latency average = 339.506 ms

> I didn't post the harness as it's currently so messy to be near
> useless to others. But if you'd like to play around,  I can tidy it up
> a bit and post it.

I'd be curious, thanks.