>maybe NOT is implemented the same way as any other >function and so it cannot be optimized using index.
That's possible, but other logical operators don't exhibit the same bahavior and will not prevent the use of indexes. That NOT is not being handled at the same _logical_ level than AND and OR is a bit disappointing. >Better example will be "NOT int_val < 3" versus "int_val >= 3". You're right, that just got "out of the keyboard" by itself ;-) >No, I didn't mean that. Apparently we have different understanding of >words "full values". :) OK then I follow you, but that only needs loading / searching some O(log N) pages from the b-tree, which hold actual column entries (full values). _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
