[
https://issues.apache.org/jira/browse/CALCITE-5240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584499#comment-17584499
]
Thomas D'Silva commented on CALCITE-5240:
-----------------------------------------
{quote}
Is the effect of your rewrite to add a duplicate bound, aligned with the
boundary of the {{FLOOR}} function? If one or both of the bounds are already
aligned, does it still add duplicate bounds?
{quote}
The view is rewritten to add a predicate that is aligned with the boundary of
the FLOOR function only if it doesn’t have an existing predicate so if one or
both bounds exist and are aligned a duplicate predicate is not added.
{quote}
The change looks pretty good. I noticed a lot of new imports in
MaterializedViewRelOptRulesTest. The test didn't previously deal much in
RexNode and RelMetaData, and now it uses them a lot. Is that an indication that
something needs to be refactored?
{quote}
I modified {{MaterializedViewFixture}} to add an optional
{{RelMetadataProvider}} that can be used to tweak costs. This is only used in
the new tests to show that materialized view will be queried if the view has
relatively less rows that the table and if the selectivity of range predicates
is smaller for smaller vs larger time ranges. I couldn't think of a better way
to refactor the test to accomplish this.
{quote}
Separately, do we need a better abstraction for time units? They pop up in the
FLOOR and CEIL functions, class Sarg, GROUP BY, and other places. I think we
need to tie all of those things together.
{quote}
It would help if we had better abstraction for time units. Currently in order
to get the time unit from a FLOOR/CEIL function we need to cast the second
operand to a {{TimeUnitRange}}.
{quote}
Can you find someone who worked on MaterializedViewAggregateRule to review this.
{quote}
I will send an email to the dev list for a review request.
> 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: 10m
> 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)
