Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Yeah. NOT IN does not have the right semantics to become an antijoin.
> If we noticed that the columns in the subquery are all guaranteed to be not
> null could we do it then?
I think you'd also have to know that the outer-query value isn't null,
plus assume that the comparison operator can't return null for two
non-nulls (but we already assume that for btree/hash equality I think).
As you said, this would never have been safe before plan invalidation,
but it might be doable now.
regards, tom lane