Re: Sequential Scan Read-Ahead

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Curt Sampson <cjs(at)cynic(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sequential Scan Read-Ahead
Date: 2002-04-25 08:33:36
Message-ID: 5.1.0.14.1.20020425160340.036b1c00@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 :) ).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-04-25 09:19:02 Re: Sequential Scan Read-Ahead
Previous Message Curt Sampson 2002-04-25 07:55:50 Re: Sequential Scan Read-Ahead