> > > I've been working on the patch to enhance our group commit behavior. > > > The patch is a dirty hack at the moment, but I'm settled on the > > > algorithm I'm going to use and I know the issues involved. > > > > One question that just came to mind is whether Simon's no-commit-wait > > patch doesn't fundamentally alter the context of discussion for this. > > Aside from the prospect that people won't really care about group > > commit if they can just use the periodic-WAL-sync approach, ISTM that > > one way to get group commit is to just make everybody wait for the > > dedicated WAL writer to write their commit record.
Yes good catch, I think we will want to merge the two. But, you won't want to wait indefinitely, since imho the dedicated WAL writer will primarily only want to write/flush full WAL pages. Maybe flush half full WAL pages only after some longer timeout. But basically this timeout should be longer than an individual backend is willing to delay their commit. > > With a > > sufficiently short delay between write/fsync attempts in the > > background process, won't that net out at about the same place as a > > complicated group-commit patch? I don't think we want the delay so short, or we won't get any grouped writes. I think what we could do is wait up to commit_delay for the dedicated WAL writer to do it's work. If it did'nt do it until timeout let the backend do the flushing itself. > I think the big question is whether commit_delay is ever going to be generally useful. It is designed to allow a higher transaction/second rate on a constantly WAL bottlenecked system, so I think it still has a use case. I think you should not compare it to no-commit-wait from the feature side (only implementation). Andreas ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq