> > > 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