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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers