From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Faster "SET search_path" |
Date: | 2023-08-07 22:39:08 |
Message-ID: | 20230807223908.GB1284531@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
0001 and 0002 LGTM. 0003 is looking pretty good, too, but I think we
should get some more eyes on it, given the complexity.
On Mon, Aug 07, 2023 at 12:57:27PM -0700, Jeff Davis wrote:
> (Aside: part of the reason set_config_option() is slow is because of
> the lookup in guc_hashtab. That's slower than some other hash lookups
> because it does case-folding, which needs to be done in both the hash
> function and also the match function. The hash lookups in
> SearchPathCache are significantly faster. I also have a patch to change
> guc_hashtab to simplehash, but I didn't see much difference.)
I wonder if it'd be faster to downcase first and then pass it to
hash_bytes(). This would require modifying the key, which might be a
deal-breaker, but maybe there's some way to improve find_option() for all
GUCs.
> But in general I'd prefer to optimize cases that are going to work
> nicely by default for a lot of users (especially switching to a safe
> search path), without the need for obscure knowledge about the
> performance implications of the session search_path. And to the extent
> that we do optimize for the pre-existing search_path, I'd like to
> understand the inherent overhead of changing the search path versus
> incidental overhead.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-08-07 22:48:38 | Re: Using defines for protocol characters |
Previous Message | Peter Geoghegan | 2023-08-07 22:18:51 | Re: Use of additional index columns in rows filtering |