"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> Would commit_delay/commit_siblings helps or we need a
> background xlog writer and notify us the completion of xlogflush is better
> (so we don't compete for this lock)?
The existing bgwriter already does a certain amount of xlog flushing
(since it must flush WAL at least as far as the LSN of any dirty page it
wants to write out). However I'm not sure that this is very effective
--- in a few strace tests that I've done, it seemed that committing
backends still ended up doing the bulk of the xlog writes, especially
if they were doing small transactions. It'd be interesting to look into
making the bgwriter (or a new dedicated xlog bgwriter) responsible for
all xlog writes. You could imagine a loop like
forever do if (something new in xlog) write and flush it; else sleep 10 msec;done
together with some kind of IPC to waken backends once xlog was flushed
past the point they needed. (Designing that is the hard part.)
But in any case, the existing commit_delay doesn't seem like it's got
anything to do with a path to a better answer, so this is not an
argument against removing it.
regards, tom lane
