Re: Converting NOT IN to anti-joins during planning - Mailing list pgsql-hackers

From Jim Finnerty
Subject Re: Converting NOT IN to anti-joins during planning
Date
Msg-id 1551843465677-0.post@n3.nabble.com
Whole thread Raw
In response to Converting NOT IN to anti-joins during planning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Converting NOT IN to anti-joins during planning
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Update does not move row across foreign partitions in v11
Next
From: David Rowley
Date:
Subject: Re: Update does not move row across foreign partitions in v11