If you only have a handful of values for C and are already going to the trouble of creating separate views for each C, you could partition your data into separate tables for each value of C and maybe create another table containing the list of values of C and maybe the number of items in each C table (if that would be useful), or other attributes common to each value of C.
Whether that makes sense depends on what else you're doing with the views. You might have to repeat queries across a set of tables and then do some work in your application to collate the results. That could be a big deal or not, depending on what you're doing. For this min example, you'd only have to query the master table. Jim On 6/11/09, Antti Nietosvaara <an...@ksenos.fi> wrote: > On Thursday 11 June 2009 16:30:12 Igor Tandetnik wrote: >> > Ah, this would indeed explain the slowdown. I was hoping views would >> > translate into the "where" part of the query, like: >> > SELECT min(C) FROM T_view; -> SELECT min(C) FROM T WHERE (C=1 OR C=2); >> >> I predict this last query wouldn't run any faster. Try it. > > You are correct. It is way too slow. > > -- > Antti Nietosvaara > Turun Turvatekniikka Oy > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
