"Qingqing Zhou" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])