On Tue, Mar 6, 2012 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
