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
