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
-
Check we don't misoptimize a NOT IN where the subquery returns no rows.
- 3396138a6de3 12.0 landed