[
https://issues.apache.org/jira/browse/CALCITE-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186819#comment-17186819
]
Julian Hyde commented on CALCITE-3409:
--------------------------------------
Let's get another couple of people to review this. Quite a few parties use the
MV mechanism, so everyone should agree to this. [~jcamacho] and [~stalbot]
spring to mind.
Rather than lists of rules, I think you should use a program, which contains an
immutable set of rules and is created using a builder. The method
{{addExtraMaterializationRules}} should be replaced by something like
{{setMaterializationProgram}}.
It may not be a good idea to make rules' constructors public. It will prevent
people from refactoring rules. We just went through CALCITE-3923 to fix the
analogous problem in planner rules, and it was painful. But I don't have an
alternative.
The mainstay of planner rules has been {{RelOptRulesTest}}. It makes it easy to
test a rule in an isolated but still realistic context. We could not have built
the library of planner rules without it. What would a similar framework look
like for materialization rules?
> Add an interface in MaterializedViewSubstitutionVisitor to allow registering
> UnifyRule
> --------------------------------------------------------------------------------------
>
> Key: CALCITE-3409
> URL: https://issues.apache.org/jira/browse/CALCITE-3409
> Project: Calcite
> Issue Type: Improvement
> Reporter: Jin Xing
> Assignee: Jin Xing
> Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In current code of MaterializedViewSubstitutionVisitor, all matching rules
> are internal defined. The existing rules support the most popular scenarios.
> But my customers sometimes ask for the ability to self define some matching
> rules, thus to support some special scenarios.
> I take below example as an illustration:
> {code:java}
> Query:
> select * from table
> where from_unixtime(_EVENT_TIME_, "yyyymmdd hh") >= "20190909 00"
> and from_unixtime(_EVENT_TIME_, "yyyymmdd hh") <= "20190909 23" ;
> Materialized View:
> select * from table
> where from_unixtime(_EVENT_TIME_, "yyyymmdd") = "20190909";{code}
> It's hard to enumerate the matching pattern for different functions in
> internal matching rules. We can expose a method to register new UnifyRules
> and allow user to extend the ability of MV matching
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
