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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Adding a LogicalRepWorker type field