Goran Thyni wrote:
>
> Vadim,
>
> Unfortunately, not all subqueries can be handled by "normal" joins: NOT IN
> is one example of this - joining by <> will give us invalid results.
>
> What is you approach towards this problem?
Actually, this is problem of ALL modifier (NOT IN is _not_equal_ ALL)
and so, we have to have not just NOT EQUAL flag but some ALL node
with modified operator.
After that, one way is put subquery into inner plan of an join node
to be sure that for an outer tuple all corresponding subquery tuples
will be tested with modified operator (this will require either
changing code of all join nodes or addition of new plan type - we'll see)
and another way is ... suggested by you:
> I got an idea that one could reverse the order,
> that is execute the outer first into a temptable
> and delete from that according to the result of the
> subquery and then return it.
> Probably this is too raw and slow. ;-)
This will be faster in some cases (when subquery returns many results
and there are "not so many" results from outer query) - thanks for idea!
>
> Personally, I was stuck by holydays -:)
> Now I can spend ~ 8 hours ~ each day for development...
>
> Oh, isn't it christmas eve right now in Russia?
Due to historic reasons New Year is mu-u-u-uch popular
holiday in Russia -:)
Vadim
