>> Does that mean for two tables, one 1000 rows another 2000 rows, it's a
>> total of 1000 X 2000 rows scanned?
>
>You got it :-(. (Unless we find what we're looking for before scanning
>all the way through --- so M*N is the worst case, but the average case
>is probably less.)
>
>> I suppose one way to slightly reduce the number of rows would be to select
>> stuff into temp tables first.
>
>7.0 is smart enough to do that if the inner query looks complicated.
>If it's just a sequential scan itself, then of course there's no win...
Ok I got it. I'm going to do simple selects and doing the intersects myself :)
Dragos.