D. Richard Hipp wrote: > There has been a recent flurry of comments about SQLite at > > http://www.reddit.com/r/programming/comments/8oed5/how_sqlite_is_tested/ > http://news.ycombinator.com/item?id=633151 > > One of the criticisms of SQLite is that it is slow to do joins. That > is true if SQLite is unable to figure out how to use an index to speed > the join. I was under the impression that SQLite actually did a > fairly reasonable job of making use of indices, if they exist. But > without indices, an k-way join takes time proportional to N^k. >
We're finishing a system which produces auto generated queries where k can potentially range from 1 to 16. The only times I have seen Sqlite slowdown were when the indexes needed tweaking. I noticed one of the comments made was that a three inner join query took 10 minutes and that the joins should have filtered the table, however, I did not notice any example, contrived or obfuscated, which would demonstrate the issue. This absence means we must rely upon the author's interpretation of what the query did being accurate. The author makes the assertion that each progressive inner join should make the search table smaller, however, just because that was the intent does not make it the reality. The fact that temp tables with no apparent indexing ran faster makes me question whether or not the initial assumption was true. I've been wrong far too often about the actual vs theoretical of my code in operation to accept anything such as this at face value; however, that caveat would apply from both directions. The author said he reported it as a bug, which implies he presented a repeatable test case. If that is so, that specific test case might merit further examination. FWIW John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
