Hello Dennis, Wednesday, June 18, 2008, 4:26:55 PM, you wrote:
DC> Teg wrote: >>> >> Yeah, it's not that fast at all. I moved away from SQLite for one part >> of my application because COUNT was slow. If the data's not in the OS >> cache, it's real slow. >> >> One possibility would be to maintain an approximate count in a >> different table. That didn't work for me because my counts were time >> dependent and depended on some RE filtering. >> DC> Are you saying you found another database that maintains accurate counts DC> of records that will be returned from a query that uses a regular DC> expression to filter the data without actually executing the query? This DC> sounds lie magic to me. How could it possibly know which regular DC> expression you are going to use in a given count query? DC> Dennis Cote No, I'm not saying that. I was just explaining why the trigger scheme or any other scheme where I keep the count in a different table won't work for me. That scheme only works if the WHERE clause is the same each time. If it's dynamic, say the user changes the date range or RE, a COUNT is unavoidable. I use SQlite in many other places in my application. I just went to custom data files for this one part of my application because SQlite didn't quite fit. One reason was the counting. I was also running into some performance issues feeding this one part at up to 70 Mbps so, a custom data file gave me the performance I needed and the way I lay out the data files gave me pretty much a direct count. I doubt the COUNT in Sqlite could be any faster. You really notice the slowdown though, the first time you access the DB and nothing's in cache. -- Best regards, Teg mailto:[EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
