|
![](/i/fill.gif) |
"Invisible" <voi### [at] dev null> wrote in message
news:4891a10d$1@news.povray.org...
> My point is that if you need to process 75% of the rows of the table,
> it's probably faster to do a sequential full scan than to use an index
> and do lots of random I/O. Obviously if you only need to process, say,
> 5% of the table, you'd be mad to not use an index...
I'm talking about range queries (all values between 1 and 100, all surnames
with first letters between N and Z). In that case you;'re not going to be
doing random IOs. One seek to find the start of the range (3 -5 random IOs),
then scan along the index leaf pages (sequential IOs). Provided all the data
required is included in the leaf pages, that is going to be faster than a
scan of the entire table.
Firstly because in general indexes are smaller than the entire table so
fewer IOs are required, second because the inapplicable 25% can be ignored
and doesn't have to be read and examined.
Of course, if you're looking for a random 75% of the table, then it's a
table scan.
Post a reply to this message
|
![](/i/fill.gif) |