On Mon, 2005-01-24 at 12:12 +0100, Manfred Koizar wrote:
> On Fri, 21 Jan 2005 23:52:51 +0000, Simon Riggs <simon@2ndquadrant.com>
> 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
