Re: Group commit and commit delay/siblings - Mailing list pgsql-performance

From Simon Riggs
Subject Re: Group commit and commit delay/siblings
Date
Msg-id 1291834852.2872.1168.camel@ebony
Whole thread Raw
In response to Re: Group commit and commit delay/siblings  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-performance
On Mon, 2010-12-06 at 23:52 -0500, Greg Smith wrote:
> Jignesh Shah wrote:
> > On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> >> I could have sworn we'd refactored that to something like
> >>        bool ThereAreAtLeastNActiveBackends(int n)
> >> which could drop out of the loop as soon as it'd established what we
> >> really need to know...I'd suggest that we just improve the
> >> coding so that we don't scan ProcArray at all when commit_siblings is 0.
> >>
> >> (I do agree with improving the docs to warn people away from assuming
> >> this is a knob to frob mindlessly.)
> >>
> > In that case I propose that we support commit_siblings=0 which is not
> > currently supported. Minimal value for commit_siblings  is currently
> > 1. If we support commit_siblings=0 then it should short-circuit that
> > function call which is often what I do in my tests with commit_delay.
> >
>
> Everybody should be happy now:  attached patch refactors the code to
> exit as soon as the siblings count is exceeded, short-circuits with no
> scanning of ProcArray if the minimum is 0, and allows setting the
> siblings to 0 to enable that shortcut:

Minor patch, no downsides. Docs checked. Committed.

--
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services



pgsql-performance by date:

Previous
From: Bryce Nesbitt
Date:
Subject: hashed subplan 5000x slower than two sequential operations
Next
From: Shrirang Chitnis
Date:
Subject: Re: hashed subplan 5000x slower than two sequential operations