[
https://issues.apache.org/jira/browse/CALCITE-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300158#comment-17300158
]
Stamatis Zampetakis commented on CALCITE-3409:
----------------------------------------------
I don't mind either about new vs old interfaces. I am concerned about bloating
the RelOptPlanner with new APIs that might be used by very few clients.
Currently we have the following proposal,
{code:java}
/**
* In addition to the internal defined materialization matching rules in
* {@link org.apache.calcite.plan.MaterializedViewSubstitutionVisitor}
* and {@link org.apache.calcite.plan.SubstitutionVisitor}, this method
* allows user to SET self defined {@link SubstitutionVisitor.UnifyRule}s,
* thus to extend the ability of substitution based materialization
* matching in different scenarios.
*/
void addMaterializationRules(List<UnifyRule> rules);
/**
* In addition to the internal defined materialization normalization rules,
* this method allows user to SET self defined {@link RelOptRule}s,
* thus to extend the ability of normalization in different scenarios.
*/
void addMvNormalizationRules(List<RelOptRule> rules);
{code}
for which my concerns are mostly the following:
* Both mention internally defined rules that cannot be changed which may work
for the usecases outlined by [~xzh_dz] but may not work for others.
* I don't think it is easy to understand the impact/relation of these APIs
unless you go and read the code that uses them which is not great for an API.
* Clients who implement the RelOptPlanner interface need to account for those
new APIs otherwise their implementation is partially broken, which is the case
for HepPlanner at the moment.
It might be me that I am a bit picky on this subject so if the others are fine
with proposal above we can move forward to finalize the PR (possibly marking
the APIs experimental).
> 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: 5h 40m
> 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)
