From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Jignesh Shah <jkshah(at)gmail(dot)com> |
Cc: | 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-07 04:52:50 |
Message-ID: | 4CFDBDA2.4050705@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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:
postgres# select name,setting,min_val,max_val from pg_settings where
name='commit_siblings';
name | setting | min_val | max_val
-----------------+---------+---------+---------
commit_siblings | 5 | 0 | 1000
It also makes it clear in the docs that a) group commit happens even
without this setting being touched, and b) it's unlikely to actually
help anyone. Those are the two parts that seem to confuse people
whenever this comes up. Thanks to Rob and the rest of the Facebook
commentators for helping highlight exactly what was wrong with the way
those were written. (It almost makes up for the slight distaste I get
from seeing "Greg likes MySQL at Facebook" on my Wall after joining in
that discussion)
I can't rebuild the docs on the system I wrote this on at the moment; I
hope I didn't break anything with my edits but didn't test that yet.
I'll add this into the next CommitFest so we don't forget about it, but
of course Jignesh is welcome to try this out at his convience to see if
I've kept the behavior he wants while improving its downside.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
Attachment | Content-Type | Size |
---|---|---|
commit-delay-refactor-v1.patch | text/x-patch | 6.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad Arkhipov | 2010-12-07 08:36:59 | Slow BLOBs restoring |
Previous Message | Jignesh Shah | 2010-12-07 03:07:44 | Re: Group commit and commit delay/siblings |