Re: [PERFORM] Hypothetical suggestions for planner, indexing improvement - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [PERFORM] Hypothetical suggestions for planner, indexing improvement
Date
Msg-id 20030507083616.F66185@flake.decibel.org
Whole thread Raw
In response to Re: [PERFORM] Hypothetical suggestions for planner, indexing improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Supposing that tab1.col1 contains 1, NULL, 2, then for an outer
> table row where col2 = 42
>
>     WHERE outer.col2 IN (SELECT col1 FROM tab1)
>
> will yield NULL (not FALSE).  But
>
>     WHERE EXISTS(SELECT * FROM tab1 WHERE col1 = outer.col2)
>
> will yield FALSE (not NULL).
>
> The distinction doesn't matter at the top level of WHERE, but it
> matters a lot underneath a NOT ...

OK, but even if a true transform can't be done, couldn't they share the
same set of code to fetch the data for the subquery? Going back to my
original post, I tend to use IN only in cases where I think the subquery
will return a small result-set, and use EXISTS elsewhere. Presumably,
the subquery for an IN will only be run once, while EXISTS will be run
as an inner-loop (I'm guessing here, I could be wrong). It might be
useful if the subquery was executed based on how many rows it
would/might return.
--
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: 7.4 features list
Next
From: "Andrew Dunstan"
Date:
Subject: CIDR in pg_hba.conf