From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Faster "SET search_path" |
Date: | 2023-08-02 06:06:56 |
Message-ID: | e6a44336e2a8f70fe5a9a3da8072e4daab155ad0.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-08-02 06:27:13 | Re: Adding a LogicalRepWorker type field |
Previous Message | Masahiko Sawada | 2023-08-02 06:03:29 | Re: Inaccurate comments in ReorderBufferCheckMemoryLimit() |