Re: Faster "SET search_path" - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Faster "SET search_path"
Date
Msg-id e6a44336e2a8f70fe5a9a3da8072e4daab155ad0.camel@j-davis.com
Whole thread Raw
In response to Re: Faster "SET search_path"  (Isaac Morland <isaac.morland@gmail.com>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()
Next
From: Peter Smith
Date:
Subject: Re: Adding a LogicalRepWorker type field