Date: Tue, 23 Aug 2005 19:12:38 -0400
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Read/Write block sizes (Was: Caching by Postgres)
In-reply-to: <d4b67d7c2b.d7c2bd4b67@bur-mail1.east.sun.com>
To: Jignesh Shah <J.K.Shah@Sun.COM>
Cc: pgsql-performance@postgresql.org
Mail-Followup-To: Jignesh Shah <J.K.Shah@Sun.COM>,
	pgsql-performance@postgresql.org
Message-id: <20050823231238.GL8667@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <d4b67d7c2b.d7c2bd4b67@bur-mail1.east.sun.com>
User-Agent: Mutt/1.5.10i

On Tue, Aug 23, 2005 at 05:29:01PM -0400, Jignesh Shah wrote:
>Actually some of that readaheads,etc  the OS does  already if it does
>some sort of throttling/clubbing of reads/writes.

Note that I specified the fully cached case--even with the workload in
RAM the system still has to process a heck of a lot of read calls.

>* Introduce a multiblock or extent tunable variable where you can
>define a multiple of 8K (or BlockSize tuneable) to read a bigger chunk
>and store it in the bufferpool.. (Maybe writes too) (Most devices now
>support upto 1MB chunks for reads and writes)

Yeah. The problem with relying on OS readahead is that the OS doesn't
know whether you're doing a sequential scan or an index scan; if you
have the OS agressively readahead you'll kill your seek performance.
OTOH, if you don't do readaheads you'll kill your sequential scan
performance. At the app level you know which makes sense for each
operation.

Mike Stone