I’d choose one correlating variable at a time then pass over the whole tree to remove it (i.e. decorrelate). Of course it’s sufficient to just deal with the tree below where the Correlate that defines the variables.
Repeat until there are no variables. That’s basically what RelDecorrelator does, IIRC. The challenge in making it into a rule is that it affects a whole sub-tree, not just N RelNodes, where N is the number of operands to the rule. Maybe that isn’t such a big challenge. Also, can we have a planning space that includes correlated and decorrelated versions of the same expressions? Probably, but I haven’t thought about it. Certainly we’d have to be careful with all the variables flying around. If I were you I’d start by writing some difficult test cases (e.g. a query with 2 or 3 nested correlations) and throw them at the decorrelator, maybe in the SqlToRelConverterTest. See what breaks. Julian On Nov 24, 2014, at 2:48 AM, Vladimir Sitnikov <[email protected]> wrote: >> I'd suggest that we put in the effort to make it more like a standard >> Calcite rule. > > Do you think one can decorrelate relations one-by-one? > Currently decorrelator takes the entire query and decorrelates. > Is there any problem with switching to a set of decorrelation rules > that match LogicalCorrelate? > > Vladimir
