On Sat, Mar 15, 2008 at 09:13:46AM -0400, Igor Tandetnik scratched on the wall: > "Jay A. Kreibich" <[EMAIL PROTECTED]> wrote > in message news:[EMAIL PROTECTED] > > indexes will slow > > writes (and more indexes will slow writes more), but should never > > slow searches. > > This is not always the case. It is possible for an index to slow down > SELECT statement, by confusing SQLite optimizer.
> Bottom line: it is useless at best, and harmful at worst, to create an > index on a column with a very small number of distinct values. Well, I did say "should".... This makes a lot of sense, however. I was aware that larger RDBMS optimizers tend to reject the use of indexes if the query is likely to return as few as 5 - 10% of the rows in a table, and this would be why. I always thought that was a low number, but if the table isn't ordered on disk I'm sure those numbers make sense. Of course, in order to make that kind of decision the optimizer needs pretty good statistics on the index, which adds more overhead. Thanks for the explanation. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
