Message-ID: <48C97793.2070909@mansionfamily.plus.com>
Date: Thu, 11 Sep 2008 20:54:59 +0100
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Greg Smith <gsmith@gregsmith.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Effects of setting linux block device readahead size
References: <70c01d1d0809092353r4ae687a3ycf3d99d43a5680cf@mail.gmail.com>
	<Pine.GSO.4.64.0809101023520.15181@westnet.com>
	<a1ec7d000809100926w28a4a57dy7c13f2942edc57ff@mail.gmail.com>
	<Pine.GSO.4.64.0809101313070.4714@westnet.com>
	<48C8AACD.5090702@mansionfamily.plus.com>
	<Pine.GSO.4.64.0809110150070.3993@westnet.com>
In-Reply-To: <Pine.GSO.4.64.0809110150070.3993@westnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Smith wrote:
> The point I was trying to make there is that even under impossibly 
> optimal circumstances, you'd be hard pressed to blow out the disk's 
> read cache with seek-dominated data even if you read a lot at each 
> seek point.  That idea didn't make it from my head into writing very 
> well though.
>
Isn't there a bigger danger in blowing out the cache on the controller 
and causing premature pageout of its dirty pages?

If you could get the readahead to work on the drive and not return data 
to the controller, that might be dandy, but I'm sceptical.

James