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