[
https://issues.apache.org/jira/browse/CALCITE-5240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598705#comment-17598705
]
Julian Hyde edited comment on CALCITE-5240 at 9/1/22 2:00 AM:
--------------------------------------------------------------
[~tdsilva], I added a proposal to CALCITE-5155. Can you please review it? For
example, do we need the {{LAST}} function I describe in note 6? You seem to be
trying to accomplish something like that with your {{getFloorMod}}.
{{getFloorMod}} needs to be moved to the right place, and needs its own unit
tests.
It seems that you have added functionality to {{RexInterpreter}}. If so, add
tests.
Modifying the *materialized view* by adding a filter copied from the query
seems like a hack. There seems to be a risk that the filter will be a applied
twice, or applied in the wrong place (e.g. to a WHERE clause of a joined
table), or a host of other things. Can you persuade me that it's not a hack?
The {{getViewWithFilter}} method doesn't seem to me an improvement over the
previous fluent code.
I see that in {{ImplicitViewPredicateShuttle}} you transform {{SEARCH}} to a
boolean combination of timestamp literals. Did you consider leaving it as
{{SEARCH}}?
As you say, the imports seem to be due to the new {{class
TestRelMdSelectivity}} and {{class TestRelMdRowCount}}. Is there a better place
for those classes to live?
was (Author: julianhyde):
[~tdsilva], I added a proposal to
https://issues.apache.org/jira/browse/CALCITE-5155. Can you please review it?
For example, do we need the {{LAST}} function I describe in note 6? You seem to
be trying to accomplish something like that with your {{getFloorMod}}.
{{getFloorMod}} needs to be moved to the right place, and needs its own unit
tests.
It seems that you have added functionality to {{RexInterpreter}}. If so, add
tests.
Modifying the *materialized view* by adding a filter copied from the query
seems like a hack. There seems to be a risk that the filter will be a applied
twice, or applied in the wrong place (e.g. to a WHERE clause of a joined
table), or a host of other things. Can you persuade me that it's not a hack?
The {{getViewWithFilter}} method doesn't seem to me an improvement over the
previous fluent code.
I see that in {{ImplicitViewPredicateShuttle}} you transform {{SEARCH}} to a
boolean combination of timestamp literals. Did you consider leaving it as
{{SEARCH}}?
As you say, the imports seem to be due to the new {{class
TestRelMdSelectivity}} and {{class TestRelMdRowCount}}. Is there a better place
for those classes to live?
> Enhance MaterializedViewRule so that it applies to rollup view for queries
> that contain a predicate on the rollup column
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-5240
> URL: https://issues.apache.org/jira/browse/CALCITE-5240
> Project: Calcite
> Issue Type: Improvement
> Reporter: Thomas D'Silva
> Assignee: Thomas D'Silva
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{MaterializedViewRule}} is not applied when a view does not have a view
> predicate but the query contains a predicate. For eg. for the following
> materialized view
> {code:java}
> SELECT eventid, floor(ts to minute), count(*) as cnt
> FROM events
> GROUP BY eventid, floor(ts TO minute)
> {code}
> If we have the following query the view is not used.
> {code:java}
> SELECT floor(ts to minute), count(*)
> FROM events
> WHERE ts > timestamp'2018-01-01 00:02:30' AND ts <= timestamp'2018-01-01
> 00:05:30'
> GROUP BY eventid, floor(ts TO minute)
> {code}
> If {{MaterializedViewRule}} is modified to automatically add the predicate
> {{ts > timestamp'2018-01-01 00:03:00' AND ts < timestamp'2018-01-01
> 00:05:00'}} to the view then the following plan can be generated that uses
> the union rewriting feature to query both the table and the view efficiently.
> {code:java}
> EnumerableAggregate(group=[{0, 1}], EXPR$2=[$SUM0($2)])
> EnumerableUnion(all=[true])
> EnumerableAggregate(group=[{0, 1}], EXPR$2=[COUNT()])
> EnumerableCalc(expr#0..1=[{inputs}], expr#2=[FLAG(MINUTE)],
> expr#3=[FLOOR($t1, $t2)], expr#4=[Sarg[(2018-01-01 00:02:30..2018-01-01
> 00:03:00), [2018-01-01 00:05:00..2018-01-01 00:05:30]]], expr#5=[SEARCH($t1,
> $t4)], eventid=[$t0], $f1=[$t3], $condition=[$t5])
> EnumerableTableScan(table=[[hr, events]])
> EnumerableCalc(expr#0..2=[{inputs}], expr#3=[Sarg[[2018-01-01
> 00:03:00..2018-01-01 00:05:00)]], expr#4=[SEARCH($t1, $t3)],
> proj#0..2=[{exprs}], $condition=[$t4])
> EnumerableTableScan(table=[[hr, MV0]])
> {code}
> The mailing list has a discussion related to this
> [https://lists.apache.org/thread/c7v85fccpbobz44y1o4z7hklomrcl299]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
