From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: Isaac Morland <isaac.morland@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Faster "SET search_path"
Date: Wed, 16 Aug 2023 15:09:43 -0700
Message-ID: <262cdb8a87c5e1fdb59ef2559c2a4a6006410dff.camel@j-davis.com> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pgsql@j-davis.com, robertmhaas@gmail.com, nathandbossart@gmail.com, isaac.morland@gmail.com
Subject: Re: Faster "SET search_path"
In-Reply-To: <262cdb8a87c5e1fdb59ef2559c2a4a6006410dff.camel@j-davis.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox