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

From Lincoln Yeoh
Subject Re: Sequential Scan Read-Ahead
Date
Msg-id 5.1.0.14.1.20020425160340.036b1c00@192.228.128.13
Whole thread Raw
In response to Re: Sequential Scan Read-Ahead  (Curt Sampson <cjs@cynic.net>)
Responses Re: Sequential Scan Read-Ahead  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
At 12:19 PM 4/25/02 +0900, Curt Sampson wrote:
>Grabbing bigger chunks is always optimal, AFICT, if they're not
>*too* big and you use the data. A single 64K read takes very little
>longer than a single 8K read.

Yes I agree that if sequential scans are done reading ahead helps.

And often doesn't cost much more- whilst waiting for the first block you 
ask for sometimes the other blocks are going to spin past first and often 
the subsystems will read and cache them anyway. At least that was what a 
disk caching program I wrote years ago did (it had a track cache and an O/S 
metadata cache[1]), I'm sure most modern HDDs will do the track caching 
amongst even more advanced stuff.


>     3. My observations of OS performance tuning over the past six
>     or eight years contradict the statement, "There's a considerable
>     cost in complexity and code in using "raw" storage too, and
>     it's not a one off cost: as the technologies change, the "fast"
>     way to do things will change and the code will have to be
>     updated to match." While optimizations have been removed over
>     the years the basic optimizations (order reads by block number,
>     do larger reads rather than smaller, cache the data) have
>     remained unchanged for a long, long time.

>BTW, please don't take me as saying that all control over physical
>IO should be done by Postgres. I just think that Posgres could do
>a better job of managing data transfer between disk and memory than
>the OS can. The rest of the things (using raw paritions, read-ahead,
>free-behind, etc.) just drop out of that one idea.

I think the raw partitions will be more trouble than they are worth. 
Reading larger chunks at appropriate circumstances seems to be the "low 
hanging fruit".

If postgresql prefers sequential scans so much it should do them better ;) 
(just being naughty!).

Cheerio,
Link.

[1] The theory was the drive typically has to jump around a lot more for 
metadata than for files. In practice it worked pretty well, if I do say so 
myself :). Not sure if modern HDDs do specialized O/S metadata caching 
(wonder how many megabytes would typically be needed for 18GB drives :) ).



pgsql-hackers by date:

Previous
From: Curt Sampson
Date:
Subject: Re: Sequential Scan Read-Ahead
Next
From: Curt Sampson
Date:
Subject: Re: Sequential Scan Read-Ahead