Re: Performance lossage in checkpoint dumping

The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> No way to group the writes to you can keep the most recent one open?
> Don't see an easy way, do you?
>>
>> No, but I haven't looked at it. I am now much more concerned with the
>> delay,

I concur. The blind write business is not important enough to hold up
the release for --- for one thing, it has nothing to do with the pgbench
results we're seeing, because these tests don't run long enough to
include any checkpoint cycles. The commit delay, on the other hand,
is a big problem.

>> and am wondering if I should start thinking about trying my idea
>> of looking for near-committers and post the patch to the list to see if
>> anyone likes it for 7.1 final. Vadim will not be back in enough time to
>> write any new code in this area, I am afraid.

> Near committers? *puzzled look*

Processes nearly ready to commit. I'm thinking that any mechanism for
detecting that might be overkill, however, especially compared to just
setting commit_delay to zero by default.

I've been sitting here running pgbench under various scenarios, and so
far I can't find any condition where commit_delay>0 is materially better
than commit_delay=0, even under heavy load. It's either the same or
much worse. Numbers to follow...

regards, tom lane