Re: Read/Write block sizes (Was: Caching by Postgres) - Mailing list pgsql-performance

From Michael Stone
Subject Re: Read/Write block sizes (Was: Caching by Postgres)
Date
Msg-id 20050823231238.GL8667@mathom.us
Whole thread Raw
In response to Re: Read/Write block sizes (Was: Caching by Postgres)  (Jignesh Shah <J.K.Shah@Sun.COM>)
Responses Re: Read/Write block sizes (Was: Caching by Postgres)  ("Jeffrey W. Baker" <jwbaker@acm.org>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Chris Browne
Date:
Subject: Re: Read/Write block sizes
Next
From: Michael Stone
Date:
Subject: Re: Read/Write block sizes