On Oct 7, 2011, at 11:52 AM, Simon Slavin wrote: > > On 7 Oct 2011, at 5:31pm, Puneet Kishor wrote: > >> assuming you have some other application level language you are using to get >> the data, you could stuff the result set into an array and then report the >> highest index of the array which might be faster than doing a second query >> for just the count. > > I'm trying to save the resources necessary for having SQLite fetch the values > which the SELECT would return. Any solution mentioned so far has not done > that. > > To see what I'm after, imagine a use interface which asked the user "Do you > really want to see all 50,000 entries that that search would return ?". If > this kind of search returns more than 100 records, there's no point in doing > it at all. I want to know the "50,000" number while placing the minimum load > on the system. >
As a person way more knowledgable than I once stated (I believe it was Igor), the database can't magically know there are 50,000 entries in the table. It has to sometime, somewhere, somehow count it. It can't just divine it. You could track the count of each table in a counts_table that you increment/decrement with TRIGGERs, and then query just that table. But that still wouldn't solve your specific problem of "how many queries are returned by a specific SELECT." Somewhere, somehow you will have to count it. Especially, note Pavel's recent, wonderful explanation of how SQLite steps through the result set handing you the data row by row. It *has* to go through the set to know how big the set is... there is no way around it. Unless you are making an app in a device with limited resources, who cares what load you put on SQLite... it won't complain. -- Puneet Kishor. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
