Re: FW: REVIEW: Allow formatting in log_line_prefix
От | David Rowley |
---|---|
Тема | Re: FW: REVIEW: Allow formatting in log_line_prefix |
Дата | |
Msg-id | CAApHDvpvfaskDTODqpTY-gNbe8WdMZV217ac5P=Jv-DUAGD4ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: FW: REVIEW: Allow formatting in log_line_prefix (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: FW: REVIEW: Allow formatting in log_line_prefix
Re: FW: REVIEW: Allow formatting in log_line_prefix |
Список | pgsql-hackers |
On Wed, Sep 25, 2013 at 1:20 AM, Robert Haas <robertmhaas@gmail.com> wrote:
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 needOuch! That's pretty painful. I agree that's not a normal workload,
> to look to see if I can speed it up a bit, although I do feel this benchmark
> is not quite 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
David
Вложения
В списке pgsql-hackers по дате отправления: