On Tue, Mar 6, 2012 at 2:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I would dismissed this out of hand at this if you said it a year ago, >> but I'm older and wiser now. At some point this cycle, I did some >> benchmarking of the subtransaction abort path, since the slowness of >> things like EXCEPTION blocks in PL/pgsql is a known sore point. I >> don't remember the exact numbers anymore, but I do remember the >> general picture, which is that constructing the error message is >> shockingly expensive compared to anything else that we do in that >> path. I dropped it at that point for lack of good ideas: it would be >> awfully nice to postpone the error message construction until we know >> that it's actually needed, but I don't see any clean (or even messy) >> way of doing that. > > I came across this thread while looking back to see if there was > anything relevant to Martin Pihlak's logging patch. It doesn't > seem to be a reason not to commit his patch, but I was a bit struck > by your comment about the cost of generating error messages. We > already knew that was expensive, which is why elog.c has provisions > to not do it if the message isn't going to be printed. I am wondering > exactly what case you were looking at in the above testing --- was it > plpgsql exception blocks? If so, I wonder if there'd be any mileage in > trying to postpone error message processing until we see if the user > actually asks for the text of the message. The SQLERRM variable would > have to become even more magic than it is now for that to work, but > since it's a wart already, maybe that's not a big objection.
/me looks to see if he still has the test case. Yep, I do. Attached. A patch I was noodling around with, but ultimately was somewhat underwhelmed by, also attached. IIRC it helps, but not a lot. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
try_but_fail.sql
Description: Binary data
expand-fmt-string-faster.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
