[
https://issues.apache.org/jira/browse/CALCITE-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625234#comment-16625234
]
Vladimir Sitnikov commented on CALCITE-1148:
--------------------------------------------
It looks like this issue breaks EnumerableMergeJoinRule.
What the rule does it matches regular Join, and uses {{convert(...)}} to apply
proper collation traits to the arguments.
org.apache.calcite.adapter.enumerable.EnumerableConvention#useAbstractConvertersForConversion
always returns false, so the subset with non-empty collation trait is empty,
and the plan is unimplementable.
[~minjikim], [~julianhyde], would you please clarify why canConvertConvention
and useAbstractConvertersForConversion default to false?
> Trait conversion broken for RelTraits other than Convention
> -----------------------------------------------------------
>
> Key: CALCITE-1148
> URL: https://issues.apache.org/jira/browse/CALCITE-1148
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: MinJi Kim
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.9.0
>
>
> RelTraits (e.g. RelCollationTrait and RelDistributionTrait) fail to convert
> in calcite core. Convention is handled specially at the root node (with
> VolcanoPlanner.ensureRootConverters()), but this assumes that convention
> conversions are not necessary underneath the root, which may not necessarily
> be true. In order for RelTrait conversions to work, there is a need to have
> converters (via AbstractConverters which use RelTraitDef.convert()).
> In a previous commit (b312031), AbstractConverters were added too
> aggressively. For example, even if RelTraitDef.canConvert() returns false,
> AbstractConverters were superfluously added. As a result, many plans would
> take a lot longer to plan (as pointed by 3b55c35). But removing the
> AbstractConverters means that RelTrait conversions are not handled properly
> in calcite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
