Re: Group commit and commit delay/siblings

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jignesh Shah <jkshah(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rob Wultsch <wultsch(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Group commit and commit delay/siblings
Date: 2010-12-08 19:00:52
Message-ID: 1291834852.2872.1168.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Shrirang Chitnis 2010-12-08 19:05:48 Re: hashed subplan 5000x slower than two sequential operations
Previous Message Bryce Nesbitt 2010-12-08 18:53:58 hashed subplan 5000x slower than two sequential operations