Re: Sequential Scan Read-Ahead

Поиск
Список
Период
Сортировка
От Curt Sampson
Тема Re: Sequential Scan Read-Ahead
Дата
Msg-id Pine.NEB.4.43.0204251035340.445-100000@angelic.cynic.net
обсуждение исходный текст
Ответ на Re: Sequential Scan Read-Ahead  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Sequential Scan Read-Ahead  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction