In the current implementation, multiplicity of each tuple is stored in ivm_count__ column in views. When SELECT is issued for views with duplicate, the view is replaced with a subquery in which each tuple is joined with generate_series function in order to output tuples of the number of ivm_count__.
This is problematic for following reasons:
The overhead is huge. When almost of tuples in a view are selected, it takes much longer time than the original query. This loses the meaning of materialized views.
Optimizer can not estimate row numbers correctly because this have to know __ivm_count__ values stored in tuples.
System columns of materialized views like cmin, xmin, xmax can not be used because a view is replaced with a subquery.
Therefore, we need another design to handle tuple duplicate which doesn't use ivm_count__ and generate_series. Note that we still have to use ivm_count__ for supporting DISTINCT and aggregates.
In the current implementation, multiplicity of each tuple is stored in ivm_count__ column in views. When SELECT is issued for views with duplicate, the view is replaced with a subquery in which each tuple is joined with generate_series function in order to output tuples of the number of ivm_count__.
This is problematic for following reasons:
The overhead is huge. When almost of tuples in a view are selected, it takes much longer time than the original query. This loses the meaning of materialized views.
Optimizer can not estimate row numbers correctly because this have to know __ivm_count__ values stored in tuples.
System columns of materialized views like cmin, xmin, xmax can not be used because a view is replaced with a subquery.
Therefore, we need another design to handle tuple duplicate which doesn't use ivm_count__ and generate_series. Note that we still have to use ivm_count__ for supporting DISTINCT and aggregates.