s.breith...@staubli.com wrote: > Now I noticed that the speed of selects are much faster with fields > that are indexed
Well, that's pretty much the point of having an index in the first place. Why do you find this fact surprising? > I´ve read that only one index is used per where (I think join is > nothing > else here) No - one index per table. SQLite could use as many indexes as tables mentioned in the FROM clause. > The questions: > Does it mean only one index can be used per join or one index for each > table of the join? One for each table. > Does the output mean, that the query runs over the fast index and > there is > nothing to improve (as long > as I use the database always in that way) or does it just explain > that one > index is used? I don't understand this question. > Or in other words, does this print mean that I use the database in > perfect > way (speaking only of indexes): > 0|0|TABLE ActiveError AS AE USING PRIMARY KEY ORDER BY > 1|1|TABLE ErrorDefinition AS ED USING PRIMARY KEY > 2|2|TABLE ErrorGroupDefinition AS EG1 USING PRIMARY KEY > 3|3|TABLE ErrorGroupDefinition AS EG2 USING PRIMARY KEY Well, it's hard to prove that there's absolutely no better way to execute a query - especially since you don't actually show the query in question, nor the definition of tables involved. Igor Tandetnik
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
