Re: Change GUC hashtable to use simplehash?
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2023-11-19T22:54:41Z
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
- v3-0005-Use-SH_STORE_HASH-for-GUC-hash-table.patch (text/x-patch) patch v3-0005
- v3-0004-GUC-optimize-for-already-case-folded-names.patch (text/x-patch) patch v3-0004
- v3-0003-Avoid-duplicating-GUC-name-when-it-s-already-case.patch (text/x-patch) patch v3-0003
- v3-0002-Case-fold-earlier.patch (text/x-patch) patch v3-0002
- v3-0001-Convert-GUC-hashtable-to-use-simplehash.patch (text/x-patch) patch v3-0001
Hi,
On Fri, 2023-11-17 at 16:10 -0800, Andres Freund wrote:
> > The requested name is already case-folded in most contexts. We can
> > do a
> > lookup first, and if that fails, case-fold and try again. I'll hack
> > up
> > a patch -- I believe that would be measurable for the proconfigs.
>
> I'd just always case fold before lookups. The expensive bit of the
> case
> folding imo is that you need to do awkward things during hash
> lookups.
Attached are a bunch of tiny patches and some perf numbers based on
simple test described here:
https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com
0001: Use simplehash (without SH_STORE_HASH)
0002: fold before lookups
0003: have gen->name_key alias gen->name in typical case. Saves
allocations in typical case where the name is already folded.
0004: second-chance lookup in hash table (avoids case-folding for
already-folded names)
0005: Use SH_STORE_HASH
(These are split out into tiny patches for perf measurement, some are
pretty obvious but I wanted to see the impact, if any.)
Numbers below are cumulative (i.e. 0003 includes 0002 and 0001):
master: 7899ms
0001: 7850
0002: 7958
0003: 7942
0004: 7549
0005: 7411
I'm inclined toward all of these patches. I'll also look at adding
SH_STORE_HASH for the search_path cache.
Looks like we're on track to bring the overhead of SET search_path down
to reasonable levels. Thank you!
Regards,
Jeff Davis