I have read the DSIP, and I think the Instructions for use are clearer, but we
need more detail designs.
For example:
1. how to "refresh" the mv
If we use "insert into select", Is there any difference between this and
the user using a crontab script outside to refresh. Does this increase in
complexity match the benefits to users?
2. What about incremental update
I think this is what the user actually needs. If it is just a full update,
users can fully support it through other T+1 system, and there is no need to
put such a large amount of data into Doris for processing.
3. Does this function have some pre-request feature that need to be designed
first?
1. Resource isolation to make sure that the background refresh processing
will not affect other queries.
2. Support update/upsert for table, so that we can reflect the
"change-data" from upstream to downstream materialized views.
--
此致！Best Regards
陈明雨 Mingyu Chen
Email:
morning...@apache.org
At 2022-06-20 14:12:04, "yangzhg" <yang...@apache.org> wrote:
>I'd like to propose the support for Multi-table materialized view.
>
>At present, materialized views can be created on a single table, and can
>use pre-computed results to achieve query acceleration, but support for
>multi-table scenarios cannot be realized. Many query scenarios are
>relatively simple and the data update frequency is not high. Materialized
>views can effectively improve query performance and reduce data calculation
>
>The associated issue: https://github.com/apache/doris/issues/7503
>The DSIP WIKI:
>https://cwiki.apache.org/confluence/display/DORIS/DSIP-017%3A+Support+Multi-table+materialized+views
