Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Views / SELECT extremely slow #3580
Database-interactions in SQliteStudio are extremely slow, as soon as they are a bit more complex, e.g. views with joins or subqueries.
It looks like SQLiteStudio is doing something horribly wrong here, to get so horribly slow.
Is there any hope that this might be fixed soon? Since these delays make it quite unusable.
Steps to reproduce
Unfortunately, I cannot give you my database, but since the performance difference is so huge, it should be easy to reproduce / find.
That would be really helpful. There are two problems in fact. One is that - so called - "smart execution" has some problem understanding the query, so it falls back to "simple execution". That's one thing to be fixed and this one can be fixed even without sample db.
Still, the simple execution should work just fine anyway. It should even be slightly faster. Both ways should be fast, but if any of them were to be slower, I would suspect rather "smart" one. Therefore I'm even more confused on why is this slow...
Having a reproducible test database would help a lot with this one.
Now, I have a simplified, stripped-down version: sqlitestudio-slooow.txt
The results for this version are:
I think this problem could be solved by:
I've analyzed another case here:
Analyzing the SQLiteStudio debug-logs showed why SQLiteStudio is so horribly slow:
So, instead of a simple "SELECT * FROM view", SQLiteStudio tries to build its own query, which is over 117000 characters long, takes >200x as much time, fails, and the runs a ~300 character long query (instead of a 19 character long one). :((
As test, I've now created a simple patch which disables the "smart execution". I've attached the test-patch.
It's much faster now, and I didn't have any segfaults (which were reproducible without the patch).