Quick note to self and others:
IN() and EXISTS() in all RDB's I know of are the uncle noone mentions; that
is to say, they have different compare semantics than JOIN so the naive
strategy is to evaluate them as dependent subqueries, not correlated ones,
which would be consistent with the behavior
Dinu wrote:
> I triple-checked it and it is indeed generating different execution plans
Probably different indexes? Are these actual tables?
>> select * from t where exists (select * from lookup where x = t.x);
>> select * from t where x in (select x from lookup);
>> select t.* from t join
Thanks Clemens,
I triple-checked it and it is indeed generating different execution plans,
with the queries being absolutely equivalent. I will try to produce a
minimal test case (right now the query where this occurs is a 100 lines long
monster).
However, I am a bit confused by the examples
Constantin Emil MARINA wrote:
> I am wondering if in SQLITE the EXISTS clause is expanded and optimized in
> any way.
No.
> This is generated by the observation that 2 algebrically equivalent queries,
> SELECT WHERE EXISTS ()
> and
> SELECT WHERE id IN (SELECT ...)
> produce different
Hi all,
I am wondering if in SQLITE the EXISTS clause is expanded and optimized
in any way.
This is generated by the observation that 2 algebrically equivalent queries,
SELECT WHERE EXISTS ()
and
SELECT WHERE id IN (SELECT ...)
produce different execution plans and different performance,
5 matches
Mail list logo
