I wrote:
> We could no doubt fix this by also insisting that the left-side vars
> be provably not null, but that's going to make the patch even slower
> and even less often applicable. I'm feeling discouraged about whether
> this is worth doing in this form.
Hm ... actually, there might be a better answer: what about transforming
WHERE (x,y) NOT IN (SELECT provably-not-null-values FROM ...)
to
WHERE <antijoin condition> AND x IS NOT NULL AND y IS NOT NULL
?
Of course this would require x/y not being volatile, but if they are,
we're not going to get far with optimizing the query anyhow.
regards, tom lane