Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
