Re: PG 7.0 is 2.5 times slower running a big report - Mailing list pgsql-general

From Bruce Momjian
Subject Re: PG 7.0 is 2.5 times slower running a big report
Date
Msg-id 200005261451.KAA22742@candle.pha.pa.us
Whole thread Raw
In response to Re: PG 7.0 is 2.5 times slower running a big report  ("Matthias Urlichs" <smurf@noris.de>)
List pgsql-general
> Hi,
>
> Bruce Momjian:
> > As I remember, Linux turns off file system prefetch if a seek is done.
>
> Correct (still so for Linux 2.4).
>
> > BSD file systems turn off prefetch only if prefetched blocks remain
> > unused.
>
> "Unused" is decided when?
> Do any, all, or some percentage of prefetched blocks need to be unused?

It starts out prefetching blocks on first file read.  In later reads, if
the desired block is in the cache, it continues read-ahead and may even
scale up the read-ahead window.

If the desired block is not in the cache, it starts to think it is
reading ahead too much or random reads are being done, and scales back
the read-ahead window.

It knows if the current read is sequential from from the previous read,
and can scale up the read-ahead window in those cases.

So the case where a file is being read sequentially but in two sections
at the same time should work fine because the read-aheads are being
used.

It basically a feedback loop causing a read that is sequential from a
previous read to make the read-ahead go up, and a read that is not in
the cache to make the read-ahead go down.

At least that is how I am reading the BSDI code.  I could send a bit of
the code over, but it is pretty confusing.

--
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: createdb -- alternate locations
Next
From: Ron Peterson
Date:
Subject: SPI & file locations