Re: Faster "SET search_path"

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

In response to

Browse pgsql-hackers by date

  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()