2009/4/14 John Machin <sjmac...@lexicon.net>: >> As you can see, it takes ages and it shouldn't. > > I can't see ... why are you measuring CPU time instead of elapsed time? > what is the unit of measure? nanoseconds or centuries?
Oh, my apologies. The actual measuring happens in the code that queries the database and it shows that the original query takes cca. 0.03 seconds. Is there any way to measure time spent on a query inside the SQLite command line interface? I though the ".timer on" was just it. > What do you get when you do > SELECT COUNT(*) FROM Event WHERE bringsSchedule = 0 AND sourceMachine_id > = 9 AND virtualClock <= 1000 AND parent_fk IS NOT NULL > ? > Is that a small number or a large number? If large, consider the > possibility that in your problem query it is finding all those rows, > sorting them on "id" then throwing away all but the row with the highest > "id". It is a number circa in between 0 and 200, depends on what exactly the sourceMachine_id and virtualClock values in the query are. In this case, it's 16. > SELECT * FROM Event WHERE id = ( > SELECT MAX(id) > FROM Event > WHERE bringsSchedule = 0 > AND sourceMachine_id = 9 > AND virtualClock <= 1000 > AND parent_fk IS NOT NULL > ); > > This may well run much faster. It runs circa three times faster (thank you!), but still - 0.01 seconds for such a query? I must be doing something else wrong... -- Lukáš Petrovický http://www.petrovicky.net/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
