Re: FW: REVIEW: Allow formatting in log_line_prefix

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FW: REVIEW: Allow formatting in log_line_prefix
Date: 2013-09-24 13:20:39
Message-ID: CA+TgmoamWoTgGujzEWQeNq_n7_1fP=WmnaqZ0kX6Kaks_7iMQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-24 13:26:05 Re: Assertions in PL/PgSQL
Previous Message Robert Haas 2013-09-24 13:14:38 Re: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline