GitHub user jianlirong added a comment to the discussion: Supporting Partitioned Tables in AQUMV(Answer Query Using Materialized Views)
WoW, this is a very dreamy feature. I'd like to add a specific scenario that we need to pay close attention to when implementing this feature. It's a real-world requirement from one of our customers. Let's continue using the aforementioned partitioned table P0, and materialized views mv1 and mv2 as examples. Generally speaking, when we insert rows into P1_1, the data status of both mv0 (based on P0) and mv1 (based on P1) will change, as P1_1's parent table P1 and the root table P0 now contain more rows. However, there's a scenario where, although mv0 is based on P0, a special WHERE clause in mv0's definition causes its state to be unrelated to P1's data but tied to P2's data instead. In this case, even if data in P1_1 changes, mv0's state remains unaffected. In other words, we don't need to refresh mv0's data in this situation. This scenario typically occurs when a DBA projects data from specific partitions of a partitioned table into a materialized view. They then grant access to this materialized view to specific application users, rather than granting direct access to the entire partitioned table. This approach restricts different users' access to different data within the partitioned table. GitHub link: https://github.com/apache/cloudberry/discussions/780#discussioncomment-11663857 ---- This is an automatically sent email for dev@cloudberry.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@cloudberry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
