morrySnow commented on code in PR #66370:
URL: https://github.com/apache/doris/pull/66370#discussion_r3765851790
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -1456,6 +1457,26 @@ 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();
+ candidateMTMVs.clear();
+ candidateMVs.clear();
+ mtmvRelatedTables.clear();
Review Comment:
`tables` (query table map) and `oneLevelTables` are populated through
`getAndCacheTable()`'s `computeIfAbsent` and are never cleared between
EXECUTEs, so they keep the `TableIf` object resolved by a previous execution.
If a base table referenced by the prepared statement is dropped and re-created
with the same name between two EXECUTEs (the same-name-replacement scenario
this PR explicitly covers for MVs in
`testMvCandidateIsRebuiltAfterSameNameReplacement`), the next EXECUTE's
`BindRelation` -> `getAndCacheTable` returns the stale cached table and plans
against the dropped table's metadata. Since this reset clears
`mtmvRelatedTables` for exactly this reason, consider also clearing
`tables`/`oneLevelTables` here (they are rebuilt by
`TableCollector`/`CollectRelation` on each execution, so clearing is safe), or
documenting why they are intentionally retained.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/StatementContext.java:
##########
@@ -1456,6 +1457,26 @@ 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();
+ candidateMTMVs.clear();
+ candidateMVs.clear();
+ mtmvRelatedTables.clear();
+
plannerHooks.removeIf(InitMaterializationContextHook.class::isInstance);
+ materializedViewRewriteDuration = 0;
+ hints.removeIf(UseMvHint.class::isInstance);
Review Comment:
`Leading`, `Ordered` and `USE_CBO_RULE`/`NO_USE_CBO_RULE` hints are also
appended to `hints` on every execution by `EliminateLogicalSelectHint`
(`extractLeading`/`extractOrdered`/`extractRule`), but only `UseMvHint`
instances are removed here. For a prepared statement executed many times, these
duplicates accumulate in `hints` without bound (they surface in EXPLAIN output
via `getHintExplainString`, and are iterated by
`getUseMvHint`/`CostBasedRewriteJob.checkRuleHintWithHintName`). If the goal of
the hint reset is to prevent per-execution hint growth, these should either be
included in the reset or deduplicated; otherwise a short comment explaining why
they are safe to retain would help future readers.
--
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]
