Re: Sequential Scan Read-Ahead

Поиск
Список
Период
Сортировка
От Lincoln Yeoh
Тема Re: Sequential Scan Read-Ahead
Дата
Msg-id 5.1.0.14.1.20020425160340.036b1c00@192.228.128.13
обсуждение исходный текст
Ответ на Re: Sequential Scan Read-Ahead  (Curt Sampson <cjs@cynic.net>)
Ответы Re: Sequential Scan Read-Ahead  (Curt Sampson <cjs@cynic.net>)
Список 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 по дате отправления:

Предыдущее
От: Curt Sampson
Дата:
Сообщение: Re: Sequential Scan Read-Ahead
Следующее
От: Curt Sampson
Дата:
Сообщение: Re: Sequential Scan Read-Ahead