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@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