Re: Faster "SET search_path"
От | Jeff Davis |
---|---|
Тема | Re: Faster "SET search_path" |
Дата | |
Msg-id | 52d12be414288cc6bc95d0f1017156a68b66a653.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Faster "SET search_path" (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Mon, 2023-11-20 at 17:13 -0800, Jeff Davis wrote: > Will commit 0005 soon. Committed. > I also attached a trivial 0006 patch that uses SH_STORE_HASH. I > wasn't > able to show much benefit, though, even when there's a bucket > collision. Perhaps there just aren't enough elements to matter -- I > suppose there would be a benefit if there are lots of unique > search_path strings, but that doesn't seem very plausible to me. If > someone thinks it's worth committing, then I will, but I don't see > any > real upside or downside. I tried again by forcing a hash table with ~25 entries and 13 collisions, and even then, SH_STORE_HASH didn't make a difference in my test. Maybe a microbenchmark would show a difference, but I didn't see much reason to commit 0006. (There's also no downside, so I was tempted to commit it just so I wouldn't have to put more thought into whether it's a problem or not.) Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: