github-actions[bot] commented on code in PR #66370:
URL: https://github.com/apache/doris/pull/66370#discussion_r3710495627
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -1443,6 +1443,22 @@ public Map<BaseTableInfo, Collection<Partition>>
getMvCanRewritePartitionsMap()
return mvCanRewritePartitionsMap;
}
+ /** Clear materialized-view planning state retained by a prepared
statement between executions. */
+ public void resetMaterializedViewStateForPreparedExecution() {
+ tableUsedPartitionNameMap.clear();
+ commonTableIdToRelationIdToMap.clear();
+ mvCanRewritePartitionsMap.clear();
+ materializedViewRewriteDuration = 0;
+ hints.removeIf(UseMvHint.class::isInstance);
+ tmpPlanForMvRewrite.clear();
+ rewrittenPlansByMv.clear();
+ needPreMvRewriteRuleMasks.clear();
+ needPreMvRewrite = false;
+ preMvRewritten = false;
+ materializationRewrittenSuccessSet.clear();
+ relationIdToStatisticsMap.clear();
Review Comment:
**[P1] Clear retained MV candidates before rebuilding them**
A dropped MTMV can still be selected on the next execution:
```text
EXECUTE 1: ResultSink -> Scan(base) candidateMTMVs={mv_old}
DROP MATERIALIZED VIEW mv_old
EXECUTE 2: ResultSink -> Scan(mv_old [dropped, old table id])
```
DROP marks the old object `isDropped` and removes it from the live relation
manager, but this reset leaves `candidateMTMVs`/`mtmvRelatedTables` alive.
`getAvailableMTMVs` then consumes the retained set directly and checks rewrite
status/partitions, not `isDropped` or the current catalog generation;
`AsyncMaterializationContext` can consequently generate a scan from that old
object and partition IDs. Clear `candidateMTMVs`, `candidateMVs`, and
`mtmvRelatedTables` here so collection rebuilds them, and cover DROP or
same-name replacement between two real EXECUTEs.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -1443,6 +1443,22 @@ public Map<BaseTableInfo, Collection<Partition>>
getMvCanRewritePartitionsMap()
return mvCanRewritePartitionsMap;
}
+ /** Clear materialized-view planning state retained by a prepared
statement between executions. */
+ public void resetMaterializedViewStateForPreparedExecution() {
+ tableUsedPartitionNameMap.clear();
+ commonTableIdToRelationIdToMap.clear();
+ mvCanRewritePartitionsMap.clear();
+ materializedViewRewriteDuration = 0;
+ hints.removeIf(UseMvHint.class::isInstance);
Review Comment:
**[P2] Remove retained MV hooks when rewrite is disabled**
An enabled execution installs `InitMaterializationContextHook.INSTANCE` in
this reused context. If the session then disables MV rewrite,
`AddInitMaterializationHook` merely declines to add another hook; it does not
remove the old one. `containMaterializedViewHook` therefore remains true, so
`CollectRelation` still discovers MVs and `lock()` still acquires all retained
MV-related table locks before `initMaterializationContext` finally rechecks the
disabled flag. A writer holding any such lock can make a base-table EXECUTE
wait for the one-minute planner timeout or fail even though MV rewrite is off.
Remove only materialization hook instances here (preserving unrelated hooks)
and clear their candidate/related-table state so the current collect pass can
re-add them only when enabled.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
