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
