> Are there reasons not to implement optimization in the first case? Except > for this is not most requested one :)
I guess because this case is highly specific and it's behavior should depend on particular constants used. Put there for example Id >> 54 = 1000 and now we should make optimizer guess right away that query will never return any rows. > Btw, actually, sometimes when several small fields exists and they should be > indexed, one can pack them into id(rowid) to save space and the first syntax > will allow querying more naturally Only for the field placed in the highest valued bits. Fields in lower valued bits will have to use '&' operator which can't use index anyway. Pavel On Tue, Jul 20, 2010 at 8:43 AM, Max Vlasov <max.vla...@gmail.com> wrote: > Hi, > as long as I see currently bitwise right does not use index > > CREATE TABLE [TestTable] ([Id] INTEGER PRIMARY KEY AUTOINCREMENT); > > EXPLAIN QUERY PLAN SELECT * FROM TestTable WHERE Id >> 12 = 1000; > : TABLE TestTable > > Sure I can replace it with the following query > > EXPLAIN QUERY PLAN SELECT * FROM TestTable WHERE Id BETWEEN 1000 << 12 AND > (1001 << 12)-1; > : TABLE TestTable USING PRIMARY KEY > > But the first syntax is more straightforward. > Are there reasons not to implement optimization in the first case? Except > for this is not most requested one :) > Btw, actually, sometimes when several small fields exists and they should be > indexed, one can pack them into id(rowid) to save space and the first syntax > will allow querying more naturally > > Thanks, > > Max Vlasov > maxerist.net > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
