From: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
---|---|
To: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
Cc: | Jignesh Shah <J(dot)K(dot)Shah(at)Sun(dot)COM>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Read/Write block sizes (Was: Caching by Postgres) |
Date: | 2005-08-23 23:44:10 |
Message-ID: | 1124840650.12932.1.camel@toonses.gghcwest.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Poe | 2005-08-24 01:25:43 | Re: Read/Write block sizes |
Previous Message | Jim C. Nasby | 2005-08-23 23:36:08 | Re: Read/Write block sizes |