Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Optimize commit_siblings in two ways to improve group commit.

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Optimize commit_siblings in two ways to improve group commit.
Date: 2010-12-08 22:43:29
Message-ID: 4D000A11.2040903@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Tom Lane wrote:
> I'm not entirely convinced that zero commit_siblings is a better
> default than small positive values, but it's certainly plausible.
>   

Not being allowed to set it to zero was certainly a limitation worth 
abolishing though; that has been the case before now, for those who 
didn't see the thread on the performance list.  I think that on the sort 
of high throughput system likely to benefit from this behavior, whether 
commit_siblings is zero or five doesn't matter very much--those people 
should cross the siblings threshold very quickly regardless.  The main 
arguments in favor of making the default lower aren't as exciting now 
that it jumps out of the loop early once finding the requisite number.

I like keeping the default at 5 though.  It keeps the person who 
experiments with increasing commit_delay from suffering when there are 
in reality not a lot of active connections.  There are essentially two 
foot-guns you have to aim before you run into the worst case here, which 
is making every single commit wait for the delay when there's really 
only one active process committing.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-12-08 22:45:01
Subject: Re: Review: Extensions Patch
Previous:From: Tom LaneDate: 2010-12-08 22:09:16
Subject: Re: serializable read only deferrable

pgsql-committers by date

Next:From: Tom LaneDate: 2010-12-09 01:02:29
Subject: pgsql: Force default wal_sync_method to be fdatasync on Linux.
Previous:From: Tom LaneDate: 2010-12-08 21:57:33
Subject: Re: [COMMITTERS] pgsql: Optimize commit_siblings in two ways to improve group commit.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group