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
