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

Re: Group commit and commit delay/siblings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jignesh Shah <jkshah(at)gmail(dot)com>, 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-06 17:55:09
Message-ID: 28624.1291658109@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> And the expensive part of the overhead beyond the delay itself is 
> CountActiveBackends(), which iterates over the entire procArray 
> structure.

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.  In general it's unclear that this'd really save
much, since in a large fraction of executions the answer would be
"no", and then you can't drop out of the loop early, or at least not
very early.  But it clearly wins when n == 0 since then you can just
return true on sight.

> As for why this somewhat weird feature hasn't been removed yet, it's 
> mainly because we have some benchmarks from Jignesh proving its value in 
> the hands of an expert.

Removal has been proposed several times, but as long as it's off by
default, it's fairly harmless to leave it there.  I rather expect
it'll stay as it is until someone proposes something that actually works
better.  In particular I see no advantage in simply deleting some of the
parameters to the existing code.  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.)

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-12-06 18:03:44
Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Previous:From: Robert HaasDate: 2010-12-06 17:10:19
Subject: Re: Performance under contention

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