Re: Sequential Scan Read-Ahead - Mailing list pgsql-hackers

From Curt Sampson
Subject Re: Sequential Scan Read-Ahead
Date
Msg-id Pine.NEB.4.43.0204251035340.445-100000@angelic.cynic.net
Whole thread Raw
In response to Re: Sequential Scan Read-Ahead  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Sequential Scan Read-Ahead  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Wed, 24 Apr 2002, Bruce Momjian wrote:

> We expect the file system to do re-aheads during a sequential scan.
> This will not happen if someone else is also reading buffers from that
> table in another place.

Right. The essential difficulties are, as I see it:
   1. Not all systems do readahead.
   2. Even systems that do do it cannot always reliably detect that   they need to.
   3. Even when the read-ahead does occur, you're still doing more   syscalls, and thus more expensive kernel/userland
transitions,than   you have to.
 

Has anybody considered writing a storage manager that uses raw
partitions and deals with its own buffer caching? This has the potential
to be a lot more efficient, since the database server knows much more
about its workload than the operating system can guess.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC
 



pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Bruce Momjian
Date:
Subject: Re: Vote totals for SET in aborted transaction