You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Mou Wu <wu...@outlook.com> on 2022/12/30 09:51:53 UTC

[Possible Bug] Materialized view rewriting may cause circular dependency because of union rewriting

Hi all:

A potential circular dependency has been found in my recent work caused by materialized view union rewriting, but I am not sure if it is bug, maybe it’s by design. That's why I send a email instead of creating a JIRA issue directly.

I write a simple example to describe the problem, consider a query, we call the query is filter#1, just like:

Filter(condition=[AND(ISNOTNULL($0), ISNOTNULL($1))])
    Project(a=[$0], b=[$1])
	Filter(condition=[EQ($0, ‘o')])
            TableScan(table=[p.src])

And there is a materialized view, we call it mv#1, just like:

Project(a=[$0], b=[$1])
    Filter(condition=[AND(ISNOTNULL($0), ISNOTNULL($1), EQ($0, ‘o'))])
        TableScan(table=[p.src])

Materialized view union rewriting will get the result when optimizing the input of filter#1:

Union(all=[true])
    TableScan(table=[mv#1])
    Project(a=[$0], b=[$1])
        Filter(condition=[AND(OR(ISNULL($0), ISNULL($1)), EQ($0, ‘o'))])
            TableScan(table=[p.src])

We call the union is union#1.

And when we optimize filter#1, materialized view rewriting will get the result:

TableScan(table=[mv#1])

So the filter#1 and the mv#1 will be in a same RelSet, we call the RelSet is set#1.
And union#1 is an input of filter#1, mv#1 is an input of union#1, mv#1 and filter#1 both in set#1. So a circular dependency occurred.

Infinite loop problems will occur in  some push down optimizing rules because of the circular dependency.

I'm not sure if this kind of circular dependency is allowed in optimize phase, otherwise the infinite loop should be fixed in push down optimizing rules.


Mou Wu
Best regards