Re: Group Commit

Should we remove these now that we have async commit?

#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000

They seem unfixable.

---------------------------------------------------------------------------

Simon Riggs wrote:
> On Tue, 2007-04-10 at 11:40 +0100, Heikki Linnakangas wrote:
> > Tom Lane wrote:
> > > Heikki Linnakangas <heikki(at)enterprisedb(dot)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.
>
> I was certainly intending that it would.
>
> > > 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.
>
> Agreed.
>
> > 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.
>
> My feeling was that I couldn't get both done for 8.3, and that including
> the WAL Writer in 8.3 would make the dev path clearer for a later
> attempt upon group commit.
>
> I think it was worth exploring whether it would be easy, but I think we
> can see it'll take a lot of work to make it "fly right".
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +