On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > A prototype patch is posted to -patches, which is WORK IN PROGRESS. > > [This patch matches discussion thread on -hackers.] > > What does this accomplish other than adding syntactic sugar over a > feature that really doesn't work well anyway? I don't see any point > in encouraging people to use commit_delay in its present form. If we > had a portable solution for millisecond-or-so waits then maybe it would > work ...
This patch doesn't intend to implement group commit. I've changed the meaning of commit_delay, sorry if that confuses. You and I discussed this in Toronto actually, IIRC. The best way to describe this proposal is deferred fsync, so perhaps a different parameter commit_fsync_delay would be more appropriate. Bruce has requested this feature many times from me, so I thought it about time to publish. The key point is that COMMIT NOWAIT doesn't wait for group commit to return, it just doesn't wait at all - leaving someone else to flush WAL. It's much better than fsync=off. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
