Re: NOT IN subquery optimization

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, David Rowley <david.rowley@2ndquadrant.com>, Richard Guo <riguo@pivotal.io>, "Li, Zheng" <zhelli@amazon.com>, "Finnerty, Jim" <jfinnert@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-03-01T16:44:17Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On March 1, 2019 4:53:03 AM PST, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> On Fri, 1 Mar 2019 at 15:27, Richard Guo <riguo@pivotal.io> wrote:
>>> 1. The patch would give wrong results when the inner side is empty.
>>> 2. Because of the new added predicate 'OR (var is NULL)', we cannot
>>> use hash join or merge join to do the ANTI JOIN.

> I've not checked, but could we please make sure these cases are covered
> in the regression tests today with a single liner?

I'm not sure if the second one is actually a semantics bug or just a
misoptimization?  But yeah, +1 for putting in some simple tests for
corner cases right now.  Anyone want to propose a specific patch?

			regards, tom lane


Commits

  1. Check we don't misoptimize a NOT IN where the subquery returns no rows.