Re: Performance lossage in checkpoint dumping

On Sat, 17 Feb 2001, Tom Lane wrote:

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

Okay, if the whole commit_delay is purely means as a performance thing,
I'd say go with lowering the default to zero for v7.1, and once Vadim gets
back, we can properly determine why it appears to improve performance in
his case ... since I believe his OS of choice is FreeBSD, and you
mentioned doing tests on it, I can't see how he'd have a more fine
grain'd select() then you have for testing ...