From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION } |
Date: | 2023-12-07 20:45:27 |
Message-ID: | 00f78197265c55d200d22ad87ff48fb623f2bdaa.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2023-11-21 at 09:24 -0500, Robert Haas wrote:
> As to the first, could we
> remove the setjmp() and instead have abort-time processing know
> something about this? For example, imagine we just push something
> onto
> a stack like we do for ErrorContextCallback, do whatever, and then
> pop
> it off. But if an error is thrown then the abort path knows to look
> at
> that variable and do whatever.
If I remove the TRY/CATCH entirely, it shows there's room for ~200ms
improvement in my test.
I attached a rough patch, which doesn't quite achieve that much, it's
more like ~100ms improvement and starts to fall within the noise. So
perhaps an improvement, but a bit disappointing. It's not a lot of
code, but it's not trivial either because the nesting level needs to be
tracked (so a subxact abort doesn't reset too much state).
Also, it's not quite as clean as it could be, because I went to some
effort to avoid an alloc/free by keeping the stack within the fcache. I
didn't pay a lot of attention to correctness in this particular patch;
I was mostly trying a few different formulations for performance
measurement.
I'm not inclined to commit this in its current form but if someone
thinks that it's a worthwhile direction, I can clean it up a bit and
reconsider.
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Eliminate-PG_TRY-CATCH-in-fmgr_security_definer.patch | text/x-patch | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2023-12-07 20:46:37 | Re: errors building on windows using meson |
Previous Message | Federico | 2023-12-07 20:21:11 | Improve upcasting for INT range and multi range types |