'IN' performance

> In the sub-select form, we pretty much suck: for each tuple in the outer
> query, we run the inner query until we find a matching value or the
> inner query ends.  This is basically a nested-loop scenario, with the
> only (minimally) redeeming social value being that the planner realizes
> it should pick a fast-start plan for the inner query.  I think it should
> be possible to convert this form into a modified kind of join (sort of
> the reverse of an outer join: rather than at least one result per
> lefthand row, at most one result per lefthand row), and then we could
> use join methods that are more efficient than nested-loop.  But no one's
> tried to make that happen yet.

That's what I was thinking...where abouts does all that activity happen?

I assume the planner knows that it doesn't have to reevaluate the subquery
if it's not correlated?

Chris