Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: mlw <markw(at)mohawksoft(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-04-17 21:16:23
Message-ID: 3CBDE627.5BE865E6@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-04-17 21:17:51 updated qCache
Previous Message Bruce Momjian 2002-04-17 21:13:04 Re: Index Scans become Seq Scans after VACUUM ANALYSE