calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remus Rusanu <rrus...@hortonworks.com>
Subject Re: Cluster mismatch between RelNodes of a query and a materialized view
Date Wed, 08 Mar 2017 12:14:53 GMT
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" <jhyde@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
     

Mime
View raw message