Re: FW: REVIEW: Allow formatting in log_line_prefix

On Wed, Sep 25, 2013 at 1:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Sep 24, 2013 at 5:04 AM, David Rowley <dgrowleyml(at)gmail(dot)com>
> wrote:
> >> So... I guess the question that I'd ask is, if you write a PL/pgsql
> >> function that does RAISE NOTICE in a loop a large number of times, can
> >> you measure any difference in how fast that function executes on the
> >> patch and unpatched code? If so, how much?
> > I do see a 15-18% slow down with the patched version, so perhaps I'll
> need
> > to look to see if I can speed it up a bit, although I do feel this
> benchmark
> > is not quite a normal workload.
>
> Ouch! That's pretty painful. I agree that's not a normal workload,
> but I don't think it's an entirely unfair benchmark, either. There
> certainly are people who suffer because of the cost of logging as
> things are; for example, log_min_duration_statement is commonly used
> and can produce massive amounts of output on a busy system.
>
> I wouldn't mind too much if the slowdown you are seeing only occurred
> when the feature is actually used, but taking a 15-18% hit on logging
> even when the new formatting features aren't being used seems too
> expensive to me.
>
>
Ok, I think I've managed to narrow the performance gap to just about
nothing but noise, though to do this the code is now a bit bigger. I've
added a series of tests to see if the padding is > 0 and if it's not then
I'm doing things the old way.

I've also added a some code which does a fast test to see if it is worth
while calling the padding processing function. This is just a simple if (*p
<= '9'), I'm not completely happy with that as it does look a bit weird,
but to compensate I've added a good comment to explain what it is doing.

Please find attached the new patch ... version v0.5 and also updated
benchmark results.

Regards

David

--
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>