I\'m having a performance problem in SQLite with a SELECT COUNT(*) on a large tables.
As I didn\'t yet receive a usable answer and I did some further testing, I edited m
From http://old.nabble.com/count(*)-slow-td869876.html
SQLite always does a full table scan for count(*). It does not keep meta information on tables to speed this process up.
Not keeping meta information is a deliberate design decision. If each table stored a count (or better, each node of the B-tree stored a count) then much more updating would have to occur on every INSERT or DELETE. This would slow down INSERT and DELETE, even in the common case where count(*) speed is unimportant.
If you really need a fast COUNT, then you can create a trigger on INSERT and DELETE that updates a running count in a separate table then query that separate table to find the latest count.
Of course, it's not worth keeping a FULL row count if you need COUNTs dependent on WHERE clauses (i.e. WHERE field1 > 0 and field2 < 1000000000).
This may not help much, but you can run the ANALYZE command to rebuild statistics about your database. Try running "ANALYZE;
" to rebuild statistics about the entire database, then run your query again and see if it is any faster.