Re: Converting NOT IN to anti-joins during planning

Actually, we're working hard to integrate the two approaches. I haven't had
time since I returned to review your patch, but I understand that you were
checking for strict predicates as part of the nullness checking criteria,
and we definitely must have that. Zheng tells me that he has combined your
patch with ours, but before we put out a new patch, we're trying to figure
out how to preserve the existing NOT IN execution plan in the case where the
materialized subplan fits in memory. This (good) plan is effectively an
in-memory hash anti-join.

This is tricky to do because the NOT IN Subplan to anti-join transformation
currently happens early in the planning process, whereas the decision to
materialize is made much later, when the best path is being converted into a
Plan.

Zheng is exploring whether we can defer doing the transformation until Plan
generation time. If we can do that, then we can generate the
highest-performing plan in all (known) cases.

-----
Jim Finnerty, AWS, Amazon Aurora PostgreSQL
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html