diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-05-01 14:39:11 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-05-01 14:39:11 -0400 |
| commit | 2057a58d1629ebffce694e3cef7f714571a88dd7 (patch) | |
| tree | d96a4bc525cc403668ae5984fe940a719639e83b /src/test | |
| parent | 74a20d0ab7c99b3efcf5dc7aac741e3b2f952a34 (diff) | |
| download | postgresql-2057a58d1629ebffce694e3cef7f714571a88dd7.tar.gz postgresql-2057a58d1629ebffce694e3cef7f714571a88dd7.zip | |
Fix mis-optimization of semijoins with more than one LHS relation.
The inner-unique patch (commit 9c7f5229a) supposed that if we're
considering a JOIN_UNIQUE_INNER join path, we can always set inner_unique
for the join, because the inner path produced by create_unique_path should
be unique relative to the outer relation. However, that's true only if
we're considering joining to the whole outer relation --- otherwise we may
be applying only some of the join quals, and so the inner path might be
non-unique from the perspective of this join. Adjust the test to only
believe that we can set inner_unique if we have the whole semijoin LHS on
the outer side.
There is more that can be done in this area, but this commit is only
intended to provide the minimal fix needed to get correct plans.
Per report from Teodor Sigaev. Thanks to David Rowley for preliminary
investigation.
Discussion: https://postgr.es/m/f994fc98-389f-4a46-d1bc-c42e05cb43ed@sigaev.ru
Diffstat (limited to 'src/test')
| -rw-r--r-- | src/test/regress/expected/join.out | 29 | ||||
| -rw-r--r-- | src/test/regress/sql/join.sql | 8 |
2 files changed, 37 insertions, 0 deletions
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out index 69ce7aa3b2f..87ff3657a34 100644 --- a/src/test/regress/expected/join.out +++ b/src/test/regress/expected/join.out @@ -5634,3 +5634,32 @@ reset enable_sort; drop table j1; drop table j2; drop table j3; +-- check that semijoin inner is not seen as unique for a portion of the outerrel +explain (verbose, costs off) +select t1.unique1, t2.hundred +from onek t1, tenk1 t2 +where exists (select 1 from tenk1 t3 + where t3.thousand = t1.unique1 and t3.tenthous = t2.hundred) + and t1.unique1 < 1; + QUERY PLAN +--------------------------------------------------------------------------------- + Nested Loop + Output: t1.unique1, t2.hundred + -> Hash Join + Output: t1.unique1, t3.tenthous + Hash Cond: (t3.thousand = t1.unique1) + -> HashAggregate + Output: t3.thousand, t3.tenthous + Group Key: t3.thousand, t3.tenthous + -> Index Only Scan using tenk1_thous_tenthous on public.tenk1 t3 + Output: t3.thousand, t3.tenthous + -> Hash + Output: t1.unique1 + -> Index Only Scan using onek_unique1 on public.onek t1 + Output: t1.unique1 + Index Cond: (t1.unique1 < 1) + -> Index Only Scan using tenk1_hundred on public.tenk1 t2 + Output: t2.hundred + Index Cond: (t2.hundred = t3.tenthous) +(18 rows) + diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql index 4fc8fd50cd5..a36e29f462e 100644 --- a/src/test/regress/sql/join.sql +++ b/src/test/regress/sql/join.sql @@ -1856,3 +1856,11 @@ reset enable_sort; drop table j1; drop table j2; drop table j3; + +-- check that semijoin inner is not seen as unique for a portion of the outerrel +explain (verbose, costs off) +select t1.unique1, t2.hundred +from onek t1, tenk1 t2 +where exists (select 1 from tenk1 t3 + where t3.thousand = t1.unique1 and t3.tenthous = t2.hundred) + and t1.unique1 < 1; |