I created CALCITE-1681 https://issues.apache.org/jira/browse/CALCITE-1681 and I
intent to work on it for finishing HIVE-15708.
My current thinking is to create a RelCopier based on RelShuttle and add a new
abstract RelNode.copyTo(RelOptPlanner) that each concrete Rel type must
override. The Rex part is already handled by the existing RexCopier.
Thanks,
~Remus
On 3/6/17, 12:30 PM, "Julian Hyde" <jh...@apache.org> wrote:
Every RelNode belongs to a RelOptCluster, and basically there is one
RelOptCluster created each time a query is prepared. When working with
materialized views, the view’s query is represented as a tree of RelNodes, that
tree is used for optimizing more than one query. When planning a particular
query, the nodes of that query will have a different RelOptCluster than the
nodes of the materialized view(s) they are matched against.
How do we deal with this? Do we copy the nodes into the query’s cluster
once we have found a match? If so, how? I couldn’t find a sub-class of
RelVisitor or RelShuttle that copies trees to a different RelOptCluster.
By the way, https://issues.apache.org/jira/browse/CALCITE-1536
<https://issues.apache.org/jira/browse/CALCITE-1536> aims to improve the
RelNode life-cycle but I don’t think it will solve this problem.
Julian
