Re: Faster "SET search_path"

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Faster "SET search_path"
Date: 2023-08-03 06:50:28
Message-ID: 7e8d116e4ea8c0ba059876267c9b6bbb7fec8a0d.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2023-08-01 at 21:52 -0700, Nathan Bossart wrote:
> I
> typically see this done with two ѕeparate lists and forboth().

Agreed, done.

>
> Any reason not to use hash_combine() here?

Thank you, fixed.

> > I changed it to move the hook so that it's called after retrieving
> > from
> > the cache.
...
> I think you are right.  This adds some complexity, but I don't have
> anything else to propose at the moment.

I reworked it a bit to avoid allocations in most cases, and it only
reprocesses the oidlist and runs the hooks when necessary (and even
then, still benefits from the cached OIDs that have already passed the
ACL checks).

Now I'm seeing timings around 7.1s, which is starting to look really
nice.

>
> I'm not following why this logic was moved.

There was previously a comment:

"We want to detect the case where the effective value of the base
search path variables didn't change. As long as we're doing so, we can
avoid copying the OID list unnecessarily."

But with v2 the copy had already happened by that point. In v3, there
is no copy at all.
>

Regards,
Jeff Davis

Attachment Content-Type Size
v3-0001-Transform-proconfig-for-faster-execution.patch text/x-patch 5.8 KB
v3-0002-Optimize-check_search_path.patch text/x-patch 4.3 KB
v3-0003-Add-cache-for-recomputeNamespacePath.patch text/x-patch 16.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tender wang 2023-08-03 06:55:03 Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Previous Message Andy Fan 2023-08-03 06:49:23 Re: Fix incorrect start up costs for WindowAgg paths (bug #17862)