To: Gregory Stark <stark@enterprisedb.com>
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: <871wbi95nb.fsf@oxford.xeocode.com> 
References: <4720FB72.8060800@sun.com> <26010.1193345641@sss.pgh.pa.us>
	<871wbi95nb.fsf@oxford.xeocode.com>
Comments: In-reply-to Gregory Stark <stark@enterprisedb.com>
	message dated "Thu, 25 Oct 2007 23:43:52 +0100"
Date: Thu, 25 Oct 2007 20:51:07 -0400
Message-ID: <29721.1193359867@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Gregory Stark <stark@enterprisedb.com> writes:
> 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. 

AFAIR we never did get any clear explanation of what the test case is.
I guess it must be write-mostly, else lazy XID assignment would have
helped this by reducing the rate of XID consumption.

It's still true that I'm leery of a large increase in the number of
buffers without reengineering slru.c.  That code was written on the
assumption that there were few enough buffers that a linear search
would be fine.  I'd hold still for 16, or maybe even 32, but I dunno
how much impact that will have for such a test case.

			regards, tom lane