In the last episode (Oct 17), Bob Kline said:
> On Sun, 17 Oct 1999, Mike Schwartz wrote:
> > I am suggesting a modification to MySQL that would be beneficial is
> > what's called an index scan or full index scan. Rather than using
> > the index for hashed or b-tree fast lookups of single key or index
> > values, scan the whole thing.
> That's why I asked how large the keys were for the column being
> indexed. Obviously the smaller the ratio between the values in this
> column and the size of the complete rows from which these values are
> drawn, the more profitable such a scheme is likely to be.
Something that might keep MySQL from being able to take advantage of
this (potentially very fast) search method is the fact that for any
particular table, all indexes are contained in a single file.
Depending on how MySQL stores indexes, it might have to walk this
entire indexfile (or do random I/O within it, even worse). I have a
couple of tables where my .MYI file is larger than my .MYD file, due to
the number of indexes.
Oracle stores indexes separately from each other, and I know that a
full-index scan is much faster than a full-table scan there.