You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <ju...@hydromatic.net> on 2014/07/08 21:58:18 UTC
OPTIQ-313, and PushFilterPastJoinRule during decorrelation
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
Re: OPTIQ-313, and PushFilterPastJoinRule during decorrelation
Posted by Jacques Nadeau <ja...@apache.org>.
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 <ju...@hydromatic.net> 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
>