"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. The worst case scenario goes like this. Suppose we have table t with column c (among others). All records have the same value for c - say, 1. Consider this statement: select * from t where c=1; If there is no index on c, SQLite will just look at every record and check the condition (which is always true), for O(N) complexity. But if there is an index on c, the optimizer will likely choose to use it. In this case the statement will enumerate every record in the index, and for each record perform a lookup in the main table based on ROWID (a logN operation), for a total O(NlogN) complexity. 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. Igor Tandetnik _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
