Re: Index Scans become Seq Scans after VACUUM ANALYSE

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026