[
https://issues.apache.org/jira/browse/PHOENIX-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602354#comment-14602354
]
Maryann Xue commented on PHOENIX-2078:
--------------------------------------
A possible and quick solution is to return an infinite cost in a PhoenixRel if
its input convention is not implementable. This works well so far for all the
existing test cases. Otherwise we might have to use different instances of the
opt rules with a specific Phoenix RelBuilder.
> Non-Phoenix convention Rel appear as a child of Phoenix Rel after application
> of XXXTransposeRule or other similar rules
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-2078
> URL: https://issues.apache.org/jira/browse/PHOENIX-2078
> Project: Phoenix
> Issue Type: Bug
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> For example, in the middle of the planner opt process, we have a rel subtree
> like:
> LogicalFilter
> PhoenixServerProject
> some_phoenix_rel
> And it can be matched against FilterTransposeRule, which will produce a new
> rel like
> PhoenixServerProject
> LogicalFilter
> some_phoenix_rel
> This would turn out to be issue if the LogicalFilter gets converted into a
> RelNode of some other convention later (for example, Enumerable), which means
> an Enumerable Rel could appear as a child of a Phoenix Rel which is actually
> not implementable. (In future we might be able to convert an Enumerable or
> JDBC or some other Rel into a PhoenixRel, but there should always be a
> converter Rel there.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
