Re: Faster "SET search_path"
От | Jeff Davis |
---|---|
Тема | Re: Faster "SET search_path" |
Дата | |
Msg-id | e6a44336e2a8f70fe5a9a3da8072e4daab155ad0.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Faster "SET search_path" (Isaac Morland <isaac.morland@gmail.com>) |
Список | pgsql-hackers |
On Wed, 2023-08-02 at 01:14 -0400, Isaac Morland wrote: > I don’t think the fact that an optimization might suddenly not work > in a certain situation is a reason not to optimize. What would our > query planner look like if we took that approach? ... > Instead, we should try to find ways of making the performance more > transparent. We already have some features for this, but maybe more > can be done. Exactly; for the planner we have EXPLAIN. We could try to expose GUC switching costs that way. Or maybe users can start thinking of search_path as a performance- related setting to be careful with. Or we could try harder to optimize the switching costs so that it's not so bad. I just started and I already saw some nice speedups; with a few of the easy fixes done, the remaining opportunities should be more visible in the profiler. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: