GitHub user avamingli added a comment to the discussion: Supporting Partitioned Tables in AQUMV(Answer Query Using Materialized Views)
> SQL Query Rewriting in the Planner: Regarding Part 2 of SQL Query Rewriting in the Planner, I have completed the work in #965 About the scenario: > 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. We’ve already discussed a draft approach for this feature. I propose naming this feature something like “Support Partition Pruning in Materialized View Status” and will need to conduct a deeper investigation to validate its feasibility. Here is the context: The current technique used in the planner to detect relation changes—relying on result OIDs to identify which relations have undergone data changes—cannot handle the scenario described in the comments. Specifically, an insertion into a parent table that ultimately routes data to one or more sub-partitioned tables requires knowledge of the underlying modified relations, not just the SQL semantic ones. This goes beyond the capabilities of the current implementation because the actual partition leaves being modified are dynamically expanded during execution by tuples from sub-nodes and filtered by qualifiers (e.g., during a COPY operation from a streaming data pipeline). As a result, it’s impossible to determine these changes during the planning phase. Additionally, certain functionalities, such as triggers in our MPP database, have not worked seamlessly since Greenplum. For example, a trigger designed to inspect inserted data from a sub-table is executed on the QE but lacks a mechanism to relay this information back to the QD. Implementing this feature would require a similar capability. Currently, I’ve implemented a mechanism where stats are propagated in three directions—UP, DOWN, and ALL (both UP and DOWN)—when maintaining a relation with its parents or children. However, this new approach would fundamentally change that, as an insertion into a parent table does not necessarily mean that a materialized view based on that parent table is outdated (considering the new feature, some child tables may change, but the underlying data in the materialized view might remain unaffected if partition pruning is enabled via specific qualifiers). GitHub link: https://github.com/apache/cloudberry/discussions/780#discussioncomment-12321710 ---- 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
