[Ideas] Shall we enable answer_query_using_materialized_views by default in v2.0?

[avamingli]

Description

Our AQUMV feature now comprehensively supports:

• Regular/partitioned/foreign tables
• Materialized views/ Incremental Materialized views/ Dynamic Tables
• Full/partial query replacement for most SQL constructs (Aggregation, GROUP BY, DISTINCT, ORDER BY, etc.)

After running successfully in production for over a year, this feature has demonstrated:

• Significant performance gains from direct resultset returns
• Remarkable stability in customer environments

Currently disabled by default (enable_answer_query_using_materialized_views = off), how about enabling it for v2.0 by default to benefit more users?

Are concerns?

Use case/motivation

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[yjhjstz]

plan time increased ? we can offer some data to discuss.

[avamingli]

Yes, this is an inevitable trade-off. However, compared to the significant time and resource savings provided by AQUMV—especially when handling large-scale data and SQL queries involving aggregations—the additional planning time is negligible.

In fact, after merging #1117, the planning time has already been drastically reduced from 78.942 ms to just 1.6 ms, making the impact minimal.
Additionally, we have ongoing plans for further optimizations. Therefore, this will not be a concern in practice.

[yjhjstz]

Orca planner does not support answer_query_using_materialized_views yet. So change answer_query_using_materialized_views to true, a little bit confused.

[avamingli]

In GPDB/CBDB, if a feature affects ORCA, its GUC typically follows the format optimizer_xxx. Else, most GUCs do not guarantee ORCA will use the feature by default.

Adding a note in the documentation clarifying this behavior should suffice.