To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Jignesh K. Shah" <J.K.Shah@Sun.COM>, <pgsql-performance@postgresql.org>,
	<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris
In-Reply-To: <26010.1193345641@sss.pgh.pa.us> (Tom Lane's message of "Thu\,
	25 Oct 2007 16\:54\:01 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <4720FB72.8060800@sun.com> <26010.1193345641@sss.pgh.pa.us>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Thu, 25 Oct 2007 23:43:52 +0100
Message-ID: <871wbi95nb.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
>> CLOG data is 
>> not cached in any PostgreSQL shared memory segments
>
> The above statement is utterly false, so your trace seems to indicate
> something broken.  Are you sure these were the only reads of pg_clog
> files?  Can you extend the tracing to determine which page of the file
> got read?  I am wondering if your (unspecified) test load was managing
> to touch more pages of the clog than there is room for in shared memory.

Didn't we already go through this? He and Simon were pushing to bump up
NUM_CLOG_BUFFERS and you were arguing that the test wasn't representative and
some other clog.c would have to be reengineered to scale well to larger
values. 

Also it seemed there were only modest improvements from raising the value and
there would always be a ceiling to bump into so just raising the number of
buffers isn't particularly interesting unless there's some magic numbers we're
trying to hit.

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