Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> 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. 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?
Possibly. To get efficient group commit there would need to be some kind
of signaling between the WAL writer and normal backends. I think there
is some in the patch, but I'm not sure if it gives efficient group
commit. A constant delay will just give us something similar to
commit_delay.
I've refrained from spending time on group commit until the
commit-no-wait patch lands, because it's going to conflict anyway. I'm
starting to feel we should not try to rush group commit into 8.3, unless
it somehow falls out of the commit-no-wait patch by accident, given that
we're past feature freeze and coming up with a proper group commit
algorithm would need a lot of research and testing. Better do it for 8.4
with more time, we've got enough features on plate for 8.3 anyway.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com