pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jeffrey W. Baker <jwbaker@acm.org>
To: Michael Stone <mstone+postgres@mathom.us>
Cc: Jignesh Shah <J.K.Shah@Sun.COM>
Cc: pgsql-performance@postgresql.org
Subject: Re: Read/Write block sizes (Was: Caching by Postgres)
Date: Tue, 23 Aug 2005 16:44:10 -0700
Message-ID: <1124840650.12932.1.camel@toonses.gghcwest.com> (raw)
In-Reply-To: <20050823231238.GL8667@mathom.us>
References: <d4b67d7c2b.d7c2bd4b67@bur-mail1.east.sun.com>
	<20050823231238.GL8667@mathom.us>

On Tue, 2005-08-23 at 19:12 -0400, Michael Stone wrote:
> 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.

This is why we have MADVISE_RANDOM and MADVISE_SEQUENTIAL.

-jwb



view thread (3+ messages)

Message-ID: <1124840650.12932.1.camel@toonses.gghcwest.com>
Permalink:  ../1124840650.12932.1.camel@toonses.gghcwest.com/
Also on:    postgresql.org/message-id/1124840650.12932.1.camel@toonses.gghcwest.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jwbaker@acm.org, mstone+postgres@mathom.us, J.K.Shah@Sun.COM
  Subject: Re: Read/Write block sizes (Was: Caching by Postgres)
  In-Reply-To: <1124840650.12932.1.camel@toonses.gghcwest.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox