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
