Re: FW: REVIEW: Allow formatting in log_line_prefix - Mailing list pgsql-hackers

From Robert Haas
Subject Re: FW: REVIEW: Allow formatting in log_line_prefix
Date
Msg-id CA+TgmoamWoTgGujzEWQeNq_n7_1fP=WmnaqZ0kX6Kaks_7iMQg@mail.gmail.com
Whole thread Raw
In response to Re: FW: REVIEW: Allow formatting in log_line_prefix  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: FW: REVIEW: Allow formatting in log_line_prefix
List pgsql-hackers
On Tue, Sep 24, 2013 at 5:04 AM, David Rowley <dgrowleyml@gmail.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.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline
Next
From: Robert Haas
Date:
Subject: Re: Assertions in PL/PgSQL