At 03:14 14/12/2014, you wrote: ´¯¯¯
I take the point that the only possible improvements seem to need alteration to the file structure or added maintenance which may use up cycles for something that just isn't that important to DB use in general - and I have to agree, I too have zero want for seeing more cycles used.
`---
I too generally don't have had a use for instant row counting of massive tables on a routine basis. It seems that currently the most transparent way to have an instant row count is to use triggers, which are well known to slow down things significantly, or rely on application code to monitor counts and store them in another table.
Without using slow triggers or changing the v3 file format there is still another possibility which could be implemented relatively easily. All it would need is a new pragma (or internal function) like "pragma row_count=0/1" and some code.
On invokation, the engine would create a hidden "system" table like sqlite_rowcount --similar to sqlite_sequence-- which would initially hold row counts for every table in the DB.
When parsing the schema, the mere existence of this table would trigger the update of this table in subsequent operations.
One can even imagine that it could be possible to remove entries from this table corresponding to tables which are not needing an instant count(*).
Disabling the feature would be as simple as negating the pragma or dropping the table.
This way, no operation would be significantly penalized unless this feature is actually used and the file format would remain identical.
Would this fit the v3 bill? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
