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