I am trying to integrate MaterializedViewRule into Apache Kylin. We need an index structure to find matched indexes since there are ten thousand materializations.
The current MaterializedViewRule class hierarchy has 3 different duties: 1. Pattern match: e.g. xxOnlyAggregateRule, xxOnlyJoinRule 2. Rewrite plan: i.e. MaterializedViewJoinRule and MaterializedViewAggregateRule 3. Match materialization: mainly in MaterializedViewRule#perform The integration requires us to separate matching and rewriting for different extending. We first try to find the possible materializations through indesex, and then does exact match. After that we choose the best materialization to rewrite plan. We can't use the cost interface of planner, because we have own logic to compare materialization which is hard to map to a float number. By the way, I also find the improved performance by reducing materializations to be rewritten. I extracded some matching codes from MaterializedViewRule, mainly computeCompensationPredicates, but I found the rewriting logic also includes matching logic, for example rewriteExpressions also check whether Compensation Predicates or output expression could be rewrittn or not. So my current idea is extracting some matching codes into a tool class, and then write our own rules. I would appreciate your feedback or any hints for this work.
