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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
