Re: logging in high performance systems.

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.

regards, tom lane