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
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 |