[
https://issues.apache.org/jira/browse/DERBY-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488535
]
Bryan Pendleton commented on DERBY-2526:
----------------------------------------
It's interesting that in all three of the outerjoin.sql, subqueryFlattening,
andDistinctTest
test failures, the queries that get different query plans have some
similarities: for one
thing, the failed query involves a case where there is both a join condition
and a simple restriction condition on the same column.
Here's the query from outerjoin.sql which gets a different query plan with the
patch:
select * from tt1 left outer join tt2 on tt1.c1 = tt2.c2 where tt2.c2 = 3
And here's the query from DistinctTest.java which gets a different query plan
with
the patch:
select distinct a.c1 from two a, four b where a.c1 = b.c1 and a.c3 = b.c3 and
b.c3 = 1;
And here's the query from subqueryFlattening.sql which gets a different query
plan with the patch:
select * from outer1 o where exists (select * from idx2 i, idx1 where o.c1 =
i.c1 and i.c2 = idx1.c1 and i.c2 = 1)
Note that in all 3 cases, the column that is being compared against a constant
value
is also part of the join criteria.
I thought that the transitive closure processing was only looking at join
conditions,
not at simple restriction conditions ("tt2.c2 = 3"), but perhaps I was wrong.
> Wrong query results due to column ordering in UNION view
> --------------------------------------------------------
>
> Key: DERBY-2526
> URL: https://issues.apache.org/jira/browse/DERBY-2526
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.0.0
> Reporter: Bryan Pendleton
> Assigned To: Bryan Pendleton
> Attachments: badQuery.log, derby-2526.sql, DistinctTestNotes.txt,
> firstTryPatch.diff, goodQuery.log
>
>
> I think both select statements in the attached repro script should return 1
> row, but in fact the first statement returns 1 row and the second returns
> zero rows.
> The only difference between the two statements is that the columns in the
> UNION view are listed in a different order (bvw vs. bvw2).
> This seems like a bug to me; the order of the columns in the view definition
> shouldn't matter, should it?
> As Army noted on the derby-dev list, the fact that this reproduces with 10.0
> means that it is not caused by some of the 10.2 optimizer changes. Something
> else is going wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
