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 7fee9f31c2e82948fa56fe57d68eecb0cce36f10.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
On Fri, 2023-11-17 at 15:27 -0800, Andres Freund wrote:
> At
> first I thought that that's largely because you aren't using
> SH_STORE_HASH.

I might want to use that in the search_path cache, then. The lookup
wasn't showing up much in the profile the last I checked, but I'll take
a second look.

> Then I noticed that memory usage was too large when creating many
> GUCs - a bit
> of debugging later, I figured out that that's due to guc_name_hash()
> being
> terrifyingly bad. There's no bit mixing whatsoever!

Wow.

It seems like hash_combine() could be more widely used in other places,
too? Here it seems like a worse problem because strings really need
mixing, and maybe ExecHashGetHashValue doesn't. But it seems easier to
use hash_combine() everywhere so that we don't have to think about
strange cases.

> I think, independent of this patch, it might be worth requiring that
> hash
> table lookups applied the transformation before the lookup. A
> comparison
> function this expensive is not great...

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.

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: Add pg_basetype() function to obtain a DOMAIN base type
Next
From: Andres Freund
Date:
Subject: Re: On non-Windows, hard depend on uselocale(3)