Re: Change GUC hashtable to use simplehash?

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: John Naylor <johncnaylorls@gmail.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-09T19:18:15Z

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

v1-0001-Use-new-hash-APIs-for-search-path-cache.patch (text/x-patch) patch v1-0001

On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > 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?

Still using the same basic test here:

https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com

What I did is:

   a. add your v5 patches
   b. disable optimization in a86c61c9ee
   c. add attached patch to use new hash APIs

I got a slowdown between (a) and (b), and then (c) closed the gap about
halfway. It started to get close to test noise at that point -- I could
get some better numbers out of it if it's helpful.

Also, what I'm doing in the attached path is using part of the key as
the seed. Is that a good idea or should the seed be zero or come from
somewhere else?

Regards,
	Jeff Davis