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

2010-12-08 Thread Greg Smith
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

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

2010-12-08 Thread Tom Lane
Greg Smith writes: > I then posted the patch and added it to the January CF. Unbeknownst to > me until today, Simon had the same multi-year "this itches and I can't > make it stop" feel toward these parameters, and that's how it jumped the > standard process. I think pretty much everybody who

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

2010-12-08 Thread Greg Smith
Tom Lane wrote: http://archives.postgresql.org/pgsql-performance/2010-12/msg00073.php Possibly it should have been posted to -hackers instead, but surely you read -performance? Trying to figure out what exactly commit_delay and commit_siblings did under the hood was actually the motivation

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

2010-12-08 Thread Robert Haas
On Wed, Dec 8, 2010 at 2:31 PM, Tom Lane wrote: > Robert Haas writes: >> Not that I see anything to disagree with in this patch, but what >> happened to posting patches in advance of committing them?  Or did I >> just miss that part? > > http://archives.postgresql.org/pgsql-performance/2010-12/ms

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

2010-12-08 Thread Tom Lane
Robert Haas writes: > Not that I see anything to disagree with in this patch, but what > happened to posting patches in advance of committing them? Or did I > just miss that part? http://archives.postgresql.org/pgsql-performance/2010-12/msg00073.php Possibly it should have been posted to -hacke

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

2010-12-08 Thread Robert Haas
On Wed, Dec 8, 2010 at 1:56 PM, Tom Lane wrote: > Simon Riggs writes: >> Optimize commit_siblings in two ways to improve group commit. >> First, avoid scanning the whole ProcArray once we know there >> are at least commit_siblings active; second, skip the check >> altogether if commit_siblings =

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

2010-12-08 Thread Tom Lane
Simon Riggs writes: > Optimize commit_siblings in two ways to improve group commit. > First, avoid scanning the whole ProcArray once we know there > are at least commit_siblings active; second, skip the check > altogether if commit_siblings = 0. > Greg Smith I wonder whether we shouldn't change