Re: How Postgresql Compares For Query And Load Operations

Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Hm.  The theory about simple sequential reads is that we expect the
> >> kernel to optimize the disk access, since it'll recognize that we are
> >> doing sequential access to the table file and do read-aheads.  Or that's
> >> the theory, anyway.
>
> > If it is Linux, they turn off read-ahead on the first fseek() and it
> > never gets turned on again, or so I am told.  And because we have
> > virtual file descriptors, that table remains open after random access
> > and the readahead bit doesn't get set for the next sequential scan.
>
> Ugh.  And even if we hacked the VFD code to close/reopen the file, the
> shared disk buffers might still have some entries for some blocks of
> the file, causing those blocks not to be requested during the seq scan,
> thus disabling read-ahead again.
>
> It sounds like we really ought to try to get this Linux behavior fixed
> to work more like BSD (ie, some reasonably small number of consecutive
> reads turns on read-ahead).  Red Hat guys, are you listening?

Hmmm... Bruce mentioned this yesterday while he was up here and he reiterated
his thoughts in a note this morning.  The note has been forwarded to the
appropriate people (ie. kernel folks).

Cheers,
Patrick