Message-ID: <262cdb8a87c5e1fdb59ef2559c2a4a6006410dff.camel@j-davis.com>
Subject: Re: Faster "SET search_path"
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Isaac Morland
	 <isaac.morland@gmail.com>, pgsql-hackers@postgresql.org
Date: Wed, 16 Aug 2023 15:09:43 -0700
In-Reply-To: 
 <CA+Tgmoa8uKQgak5wH0=7sL-ukqbwnCPMXA2ZW7Ccdt7tdNGkzg@mail.gmail.com>
References: <04c8592dbd694e4114a3ed87139a7a04e4363030.camel@j-davis.com>
	 <CAMsGm5fZ2xiVDLYH4-_Ld8bfe1qwY23ZLgPc7zBpH8d1WUw70A@mail.gmail.com>
	 <f555c41554c7f5ff2699c085836ea94beac09bad.camel@j-davis.com>
	 <20230802050720.GB866741@nathanxps13>
	 <CAMsGm5dt6szoTe5oAzk5nfbHHOEpMDVhLTOGWCJGCQ3Wq8+J0w@mail.gmail.com>
	 <fec7f3bea50112323d9b6e700b5e2762a14af809.camel@j-davis.com>
	 <20230807223908.GB1284531@nathanxps13>
	 <1c422b8a7f893550144a7aa4f4989ba1209ccba4.camel@j-davis.com>
	 <CA+Tgmoa8uKQgak5wH0=7sL-ukqbwnCPMXA2ZW7Ccdt7tdNGkzg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/262cdb8a87c5e1fdb59ef2559c2a4a6006410dff.camel%40j-davis.com>
Precedence: bulk

On Tue, 2023-08-15 at 13:04 -0400, Robert Haas wrote:
> I suspect that dodging the GUC stack machinery is not a very good
> idea. The timing of when TRY/CATCH blocks are called is different
> from
> when subtransactions are aborted, and that distinction has messed me
> up more than once when trying to code various things.

...

> I can't say there isn't a way to make something like what you're
> talking about here work, but I bet it will be difficult to get all of
> the corner cases right, and I suspect that trying to speed up the
> existing mechanism is a better plan than trying to go around it.

The SearchPathCache that I implemented (0003) is an example of speeding
up the existing mechnism that and already offers a huge speedup. I'll
focus on getting that in first. That patch has had some review and I'm
tempted to commit it soon, but Nathan has requested another set of eyes
on it.

To bring the overhead closer to zero we need to somehow avoid repeating
so much work in guc.c, though. If we don't go around it, another
approach would be to separate GUC setting into two phases: one that
does the checks, and one that performs the final change. All the real
work (hash lookup, guc_strdup, and check_search_path) is done in the
"check" phase.

It's a bit painful to reorganize the code in guc.c, though, so that
might need to happen in a few parts and will depend on how great the
demand is.

Regards,
	Jeff Davis