On Tue, Mar 08, 2005 at 11:20:20PM -0600, Bruno Wolff III wrote:
> On Tue, Mar 08, 2005 at 22:55:19 -0600,
> "Jim C. Nasby" <decibel@decibel.org> wrote:
> > On Tue, Mar 08, 2005 at 10:38:21PM -0600, Bruno Wolff III wrote:
> > > Not exactly. If the number of rows to be examined is on the order of 5%
> > > of the table, an index scan will probably be slower than a sequential
> > > scan. The visibility issue makes index scans slower in the case that
> >
> > Shouldn't that be 50%?
>
> No. When you are doing an index scan of a significant part of the table,
> you will fetch some heap pages more than once. You will also be fetching
> blocks out of order, so you will lose out on read ahead optimization
> by the OS. This assumes that you don't get a lot of cache hits on the
> help pages. If a significant portion of the table is cached, then the
> trade off point will be at a higher percentage of the table.
Ahh, I was thinking of a high correlation factor on the index. I still
question 5% though... that seems awefully low.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
