:: It won't be better and it might be worse. DISTINCT queries

That's what I thought.

:: not. Of course, a correlated subquery is run for every row
:: in the outer
:: select. "NOT IN" queries can't use an index, either. So,

Yes, this is what I was worried about. I was hoping that if the sub query
was static - that it would "store" the results and just reuse, but I take it
FB does not do that?

:: does not have any of the features of an efficient query, not
:: matter how you
:: look at it.

Yes. The problem is my alternative - and what Im doing now. What Im doing
now is running the select sub query - then walking it manually and for EACH
row reading a field, and then updating another...

Not sure which is worse. :)

Any suggestions?

:: Any "NOT-ed" existential subquery will be costly but the
:: least costly might be
:: ...
:: from atable A
:: where not exists (
:: select 1 from othertable B
:: where B.z = A.z)

Hmm - whats the not exists? How is that differnet from not in? What if I
just did a EXISTS not not a NOT EXISTS? Any diff?

:: Another approach is to avoid the row-by-row reprocessing of
:: the subquery
:: and instead use a left join to find the non-matches, which
:: should utilise
:: an index on B.z, if there is one, for the join search:

I need to do an update - not sure I can do a join and an update? Ive tried
this before, was not successful. Maybe I just couldn't get the syntax right
though.