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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers