Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 638291337B64 for ; Mon, 6 Dec 2010 13:55:22 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 41223-06 for ; Mon, 6 Dec 2010 17:55:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id E1F691337B39 for ; Mon, 6 Dec 2010 13:55:13 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id oB6Ht9AV028625; Mon, 6 Dec 2010 12:55:09 -0500 (EST) To: Greg Smith cc: Jignesh Shah , Rob Wultsch , postgres performance list Subject: Re: Group commit and commit delay/siblings In-reply-to: <4CFC6814.9010002@2ndquadrant.com> References: <4CFC6814.9010002@2ndquadrant.com> Comments: In-reply-to Greg Smith message dated "Sun, 05 Dec 2010 23:35:32 -0500" Date: Mon, 06 Dec 2010 12:55:09 -0500 Message-ID: <28624.1291658109@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201012/62 X-Sequence-Number: 41514 Greg Smith 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