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
