Re: Index Scans become Seq Scans after VACUUM ANALYSE
От | mlw |
---|---|
Тема | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Дата | |
Msg-id | 3CBDE627.5BE865E6@mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Index Scans become Seq Scans after VACUUM ANALYSE (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Index Scans become Seq Scans after VACUUM ANALYSE
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > mlw wrote: > > Now, given the choice of the two strategies on a table, both pretty close to > > one another, the risk of poor performance for using the index scan is minimal > > based on the statistics, but the risk of poor performance for using the > > sequential scan is quite high on a large table. > My second point, that index scan is more risky than sequential scan, is > outlined above. A sequential scan reads each page once, and uses the > file system read-ahead code to prefetch the disk buffers. Index scans > are random, and could easily re-read disk pages to plow through a > significant portion of the table, and because the reads are random, > the file system will not prefetch the rows so the index scan will have > to wait for each non-cache-resident row to come in from disk. That is a very interesting point, but shouldn't that be factored into the cost (random_tuple_cost?) In which case my point still stands.
В списке pgsql-hackers по дате отправления: