The big problem is with creation of cartesian joins on the decorrelated subtrees when join conditions are in the where clause. Basically, if we don't push down the join conditions before copying the joins, we'll get cartesian joins for all the joins that were copied to the other side of correlator rel.
Note, if you look at my original patch for decorrelation fixes, I had updated the PushFilterPastJoinRule to use copy hooks. When you refactored, you changed that implementation so that it was possible to have a singleton for the rule. I assumed that your implementation was equivalent but I have never validated. On Tue, Jul 8, 2014 at 12:58 PM, Julian Hyde <[email protected]> wrote: > Jacques, > > Do you recall why you added the line > > .addRuleInstance(PushFilterPastJoinRule.FILTER_ON_JOIN) > > in RelDecorrelator.removeCorrelationViaRule? When the rule fires, the > resultant RelNodes are not registered in the decorrelator's intricate > mapping, and therefore decorrelation fails. (There is some complicated > logic involving copy-hooks but they don't seem to apply here.) > > If I remove that line, https://issues.apache.org/jira/browse/OPTIQ-313 is > magically fixed and nothing else in the test suite breaks. > > I plan to check in the change removing that line shortly. Maybe you can > provide a test case illustrating why that line is necessary. > > Julian >
