Re: Faster "SET search_path"
От | Jeff Davis |
---|---|
Тема | Re: Faster "SET search_path" |
Дата | |
Msg-id | a91e1e771cd5ff4b5def11c04402a4548d670410.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Faster "SET search_path" (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
On Tue, 2023-08-01 at 22:07 -0700, Nathan Bossart wrote: > I wonder if this is a good enough reason to _not_ proceed with this > optimization. At the moment, I'm on the fence about it. I was wondering the same thing. It's something that could reasonably be explained to users; it's not what I'd call "magical", it's just avoiding an unnecessary SET. But I could certainly see it as a cause of confusion: "why is this query faster for user foo than user bar?". Another concern is that the default search_path is "$foo, public" but the safe search_path is "pg_catalog, pg_temp". So if we automatically switch to the safe search path for functions in index expressions (as I think we should do, at least ideally), then they'd be slow by default. We'd need to start advising people to set their search_path to "pg_catalog, pg_temp" to speed things up. I'm not opposed to this optimization, but I'm not sure about it either. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: