That’s why I say it’s hard to solve under current framework design. The example
query you provide can be, and should be, optimized during logical
transformation phase. At that moment, there shouldn’t be any cost calculation
since all we are doing is to explore equivalences. Once the
>In theory, the cardinality and uniqueness of a RelSubset should never
changed per definition of equivalent set
I agree. It is like in theory there is no difference between theory and
practice :)
What if we have select empid from (select empid from emps where empid>0)
where empid<0 ?
The
This is similar to CALCITE-2166 where a RelNode’s best cost could increase
after its input RelSubset cardinality is changed. Unfortunately there’s no easy
way to fix this with current framework design. In theory, the cardinality and
uniqueness of a RelSubset should never changed per definition
Hi,
As far as I understand, the incremental best/bestCost maintenance at
RelSubset level does not really work.
That issue is triggered a lot in MaterializationTests due to
https://issues.apache.org/jira/browse/CALCITE-3682
(MaterializationService#defineMaterialization
loses information on unique
