Re: logging in high performance systems.

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