DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	b=G5xCNUCBc6SaFQgApoiLhAuc75Ei+dk5AmAkkbCsrLVc+iqix59GUVfP0vCTIykjlM
	ThWCsadLpQ5IJK+/sSLqYkMSZJSnWV4Jo/DFb+5VwCN6XG+5Y6EFwgPOj8smZ66kC1Lp
	NEYX+zHo6tscotWsImXypNWtNo/9oLEerVIac=
Message-ID: <4C6C41B7.4060709@gmail.com>
Date: Wed, 18 Aug 2010 22:25:27 +0200
From: Yeb Havinga <yebhavinga@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Samuel Gendler <sgendler@ideasculptor.com>
CC: pgsql-performance@postgresql.org
Subject: Re: write barrier question
References: <AANLkTim0X2oZ61dzvwG_+TWf94DLEr_0Q_hecq57EZ6+@mail.gmail.com>
In-Reply-To: <AANLkTim0X2oZ61dzvwG_+TWf94DLEr_0Q_hecq57EZ6+@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Samuel Gendler wrote:
> When running pgbench on a db which fits easily into RAM (10% of RAM =
> -s 380), I see transaction counts a little less than 5K.  When I go to
> 90% of RAM (-s 3420), transaction rate dropped to around 1000 ( at a
> fairly wide range of concurrencies).  At that point, I decided to
> investigate the performance impact of write barriers.
At 90% of RAM you're probable reading data as well, not only writing. 
Watching iostat -xk 1 or vmstat 1 during a test should confirm this. To 
find the maximum database size that fits comfortably in RAM you could 
try out http://github.com/gregs1104/pgbench-tools - my experience with 
it is that it takes less than 10 minutes to setup and run and after some 
time you get rewarded with nice pictures! :-)

regards,
Yeb Havinga