From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Jignesh Shah <jkshah@gmail.com>
Cc: Rob Wultsch <wultsch@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Group commit and commit delay/siblings
Date: Mon, 06 Dec 2010 12:55:09 -0500
Message-ID: <28624.1291658109@sss.pgh.pa.us> (raw)
In-Reply-To: <4CFC6814.9010002@2ndquadrant.com>
References: <AANLkTik3dr076BMQ6MqCLZZ0x2-qxmQgWoqCR7c0ePoD@mail.gmail.com>
<AANLkTi=fUBnfR7K5uAQZkvaymuVHzUuCpeu4NOtLOMOU@mail.gmail.com>
<4CFC6814.9010002@2ndquadrant.com>
Greg Smith <greg@2ndquadrant.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, greg@2ndquadrant.com, jkshah@gmail.com, wultsch@gmail.com
Subject: Re: Group commit and commit delay/siblings
In-Reply-To: <28624.1291658109@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox