Thanks for the explanation Julian. I’ll create a JIRA to track this. Should the same be done for RelShuttle? This interface currently operate on Logical rels.
On 12/15/16, 10:55 AM, "Julian Hyde" <[email protected]> wrote: >I’ve no objection to this change in principle. We’d need to change >RelDecorrelator to use RelNode factories (ideally a RelBuilder) so that it can >create RelNodes of the appropriate sub-type. > >RelDecorrelator uses LogicalJoin etc. because that’s how it was originally >written. It’s typically used early in the planning process, so only running on >logical rels was never a hardship. Also, very few physical algebras even >support correlation, so RelDecorrelator would be a no-op on these. > >Please log a JIRA case. > >Julian > > > > >> On Dec 15, 2016, at 9:33 AM, Vineet Garg <[email protected]> wrote: >> >> Hi Julian, >> >> Reldecorrelator’s logic including all rules implemented within it are >> written to take LogicalJoin, LogicalFilter, LogicalProject etc. Since >> Logical operators are final that makes extending RelDecorrelator very >> difficult. Is there any reason why RelDecorrelator is written in this way? >> It makes more sense to have RelDecorrelator operate on Join, Filter etc. >> >> Regards, >> Vineet G > >
