You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Vineet Garg <vg...@hortonworks.com> on 2016/12/15 17:33:06 UTC
RelDecorrelator on Logical operators
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
Re: RelDecorrelator on Logical operators
Posted by Julian Hyde <jh...@gmail.com>.
> On Dec 15, 2016, at 11:53 AM, Vineet Garg <vg...@hortonworks.com> wrote:
…
> Should the same be done for RelShuttle? This interface currently operate on Logical rels.
I think you could, but it will be a breaking change, so I’m not sure that you should. If projects have sub-classed RelShuttle and have overridden methods without using @Override they will break with no warning. I suggest that you log a separate JIRA case and do it it others feel that the breakage is worth it.
Julian
Re: RelDecorrelator on Logical operators
Posted by Vineet Garg <vg...@hortonworks.com>.
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" <jh...@apache.org> 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 <vg...@hortonworks.com> 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
>
>
Re: RelDecorrelator on Logical operators
Posted by Julian Hyde <jh...@apache.org>.
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 <vg...@hortonworks.com> 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