Tom Lane wrote:
Mike Mascari <[EMAIL PROTECTED]> writes:
I curious if any of the rewriting of EXISTS and NOT EXISTS would
address the problem described by Date:
That should read "I'm curious"...
http://www.firstsql.com/iexist.htm
We are not here to redefine the SQL spec ... and especia
Mike Mascari <[EMAIL PROTECTED]> writes:
> I curious if any of the rewriting of EXISTS and NOT EXISTS would
> address the problem described by Date:
> http://www.firstsql.com/iexist.htm
We are not here to redefine the SQL spec ... and especially not to
eliminate its concept of NULL, which is wha
Joe Conway wrote:
Tom Lane wrote:
I've been thinking about how to improve the performance of queries using
"WHERE x IN (subselect)" and "WHERE x NOT IN (subselect)".
How about starting with a rule-based method to make the choice?
1. If uncorrelated: use hash-based approach - ISTM this might a
Tom Lane wrote:
I've been thinking about how to improve the performance of queries using
"WHERE x IN (subselect)" and "WHERE x NOT IN (subselect)".
In the existing implementation, the subquery result is rescanned to look
for a match to x each time the WHERE clause is executed; this essentially
ma
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about in the case of a scalar subquery eg. SELECT x IN
> (1,2,3,4,54,56,6), when there maybe hundreds of scalars?
Unrelated to my present problem.
regards, tom lane
---(end of broadcast)-
> The difficulty is that it's not clear how to choose one of these four
> ways, short of planning the *entire* query from scratch all four ways :-(.
> This seems pretty grim. Approaches #2 and #3 could be handled as local
> transformations of the WHERE clause, but we couldn't choose which to use
>
I've been thinking about how to improve the performance of queries using
"WHERE x IN (subselect)" and "WHERE x NOT IN (subselect)".
In the existing implementation, the subquery result is rescanned to look
for a match to x each time the WHERE clause is executed; this essentially
makes it work like
