On Mon, Mar 1, 2010 at 2:44 PM, Jean-Christophe Deschamps <j...@q-e-d.org> wrote: > The actual reason for the way NOT works as for now may be due to the > fact that negating a condition may cause the resulting set to be in > fact itself the union of two subsets. > Say the "where" condition K is "col = 12345". We can see the index > split into not less than four subsets: > o) N = {rows with col is null} > o) X = {rows with col < 12345} > o) Y = {rows with col = 12345} > o) Z = {rows with col > 12345} > > For the "positive" condition K, the resulset is Y. > For the negated condition K' (col <> 12345) the resulset is N u X u Z, > made of two (or three ?) distinct blocks of indexed rowids. A possible > explanation is that the current code may be unable to cope with > situations where the resultset is not index-wise contiguous.
NULL = 12345 is NULL, NOT NULL is NULL, so subset N is not part of NOT (col = 12345). -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users