To: "Josh Berkus" <josh@agliodbs.com>
Cc: <pgsql-performance@postgresql.org>,  "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Jignesh K. Shah" <J.K.Shah@sun.com>, <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris
In-Reply-To: <200710251956.56744.josh@agliodbs.com> (Josh Berkus's message of
	"Thu\, 25 Oct 2007 19\:56\:56 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <4720FB72.8060800@sun.com> <871wbi95nb.fsf@oxford.xeocode.com>
	<29721.1193359867@sss.pgh.pa.us>
	<200710251956.56744.josh@agliodbs.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Fri, 26 Oct 2007 09:07:23 +0100
Message-ID: <87wsta70zo.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Josh Berkus" <josh@agliodbs.com> writes:

> Actually, 32 made a significant difference as I recall ... do you still have 
> the figures for that, Jignesh?

Well it made a difference but it didn't remove the bottleneck, it just moved
it. IIRC under that benchmark Jignesh was able to run with x sessions
efficiently with 8 clog buffers, x + 100 or so sessions with 16 clog buffers
and x + 200 or so sessions with 32 clog buffers.

It happened that x + 200 was > the number of sessions he wanted to run the
benchmark at so it helped the benchmark results quite a bit. But that was just
an artifact of how many sessions the benchmark needed. A user who needs 1200
sessions or who has a different transaction load might find he needs more clog
buffers to alleviate the bottleneck. And of course most (all?) normal users
use far fewer sessions and won't run into this bottleneck at all.

Raising NUM_CLOG_BUFFERS just moves around the arbitrary bottleneck. This
benchmark is useful in that it gives us an idea where the bottleneck lies for
various values of NUM_CLOG_BUFFERS but it doesn't tell us what value realistic
users are likely to bump into.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com