Re: commit_delay, siblings

On Wed, Jun 29, 2005 at 08:14:36AM +0100, Simon Riggs wrote:
>
> Group commit is a well-documented technique for improving performance,
> but the gains only show themselves on very busy systems. It is possible
> in earlier testing any apparent value was actually hidden by the
> BufMgrLock issues we have now resolved in 8.1. We now see XLogInsert as
> being very nearly the highest routine on the oprofile. That tells me
> that it could now be time for group commit to show us some value, if any
> exists.
>
> DB2 and Berkeley-DB use group commit, while other rdbms use log writer
> processes which effectively provide the same thing. It would surprise me
> if we were unable to make use of such a technique, and worry me too.
>
> I would ask that we hold off on their execution, at least for the
> complete 8.1 beta performance test cycle. We may yet see gains albeit,
> as Tom points out, that benefit may only be possible on only some
> platforms.
>
> Best Regards, Simon Riggs
>
> ---------------------------(end of broadcast)---------------------------

I would like to wiegh in on Simon's side on this issue. The fact that
no benefit has been seen from the group commint yet may be in part do
to the current WAL fsync structure where a page at a time is sync'd.
I saw a patch/test just recently mentioned that showed dramatic
performance improvements, up to the level of "fsync = off", by writing
multiple blocks with a gather algorithm. I would hope that with a
similar patch, we should begin to see the benefit of the commit_delay
GUC.

Ken Marshall