Re: Change GUC hashtable to use simplehash? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Change GUC hashtable to use simplehash?
Date
Msg-id 27a7a289d5b8f42e1b1e79b1bcaeef3a40583bd2.camel@j-davis.com
Whole thread Raw
In response to Re: Change GUC hashtable to use simplehash?  (Andres Freund <andres@anarazel.de>)
Responses Re: Change GUC hashtable to use simplehash?
List pgsql-hackers
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


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: On non-Windows, hard depend on uselocale(3)
Next
From: Thomas Munro
Date:
Subject: Re: Windows default locale vs initdb