D'Arcy J.M. Cain wrote:
> On April 17, 2002 05:44 pm, mlw wrote:
> > It took a bike ride to think about this one. The supposed advantage of a
> > sequential read over an random read, in an active multitasking system, is a
> > myth. If you are executing one query and the system is doing only that
> > query, you may be right.
> >
> > Execute a number of queries at the same time, the expected benefit of a
> > sequential scan goes out the window. The OS will be fetching blocks, more
> > or less, at random.
>
> If it does you should look for another OS. A good OS will work with your
> access requests to keep them as linear as possible. Of course it has a
> slight effect the other way as well but generally lots of sequential reads
> will be faster than lots of random ones. If you don't believe that then just
> run the test that Tom suggested to calculate random_tuple_cost on your own
> system. I bet your number is higher than 1.
The two backends would have to be hitting the same table at different
spots to turn off read-ahead, but it is possible. If the backends are
hitting different tables, then they don't turn off read-ahead. Of
course, for both backends to be hitting the disk, they both would have
not found their data in the postgres or kernel cache.
-- Bruce Momjian | http://candle.pha.pa.us 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,
Pennsylvania19026
