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

From Jeff Davis
Subject Re: Faster "SET search_path"
Date
Msg-id 7e8d116e4ea8c0ba059876267c9b6bbb7fec8a0d.camel@j-davis.com
Whole thread Raw
In response to Re: Faster "SET search_path"  (Nathan Bossart <nathandbossart@gmail.com>)
List 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

pgsql-hackers by date:

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