On Mon, 2005-01-24 at 12:12 +0100, Manfred Koizar wrote: > On Fri, 21 Jan 2005 23:52:51 +0000, Simon Riggs <[EMAIL PROTECTED]> > wrote: > >Currently, we have group commit functionality via GUC parameters > > commit_delay > >and commit_siblings > > And since 7.3 we have ganged WAL writes (c.f. the thread starting at > http://archives.postgresql.org/pgsql-hackers/2002-10/msg00331.php) which > IMHO is a better solution to the same problem. Maybe the code dealing > with commit_xxx parameters should just be removed.
Thanks for making me aware of that explanatory link. The comments in the code say something along those lines...I've done time in xlog.c :( but I misunderstood the effect of that code. > Maybe the code dealing > with commit_xxx parameters should just be removed. Based upon the description, I would be inclined to agree. > Are you or is anybody else aware of benchmarks showing that group commit > via commit_xxx is still useful? Now that you mention it, no, but then I had thought other contention masked it. My understanding was that group commit could often slow performance if inappropriately applied, so seeing no benefit was not evidence that there was no benefit to be had. Actually, the reason for raising the subject was for the very reason you suggest. I'm about to benchmark the system under heavy load and was looking at ways of deciding whether that part of the code would ever be worthwhile.... the autotuning capability is a side effect of being able to dynamically measure the utility of that feature. (That thought could be applied widely). So: objective: measure whether commit_delay is worth keeping. -- Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
