seawinde commented on code in PR #66370:
URL: https://github.com/apache/doris/pull/66370#discussion_r3782453313
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/ExecuteCommand.java:
##########
@@ -91,6 +91,9 @@ public void run(ConnectContext ctx, StmtExecutor executor)
throws Exception {
}
PrepareCommand prepareCommand = preparedStmtCtx.command;
StatementContext statementContext =
preparedStmtCtx.getStatementContext();
+ // Prepared statements reuse StatementContext across executions.
Discard partition and MV
+ // planning results collected by the previous execution before
planning the current one.
+ statementContext.resetMaterializedViewStateForPreparedExecution();
Review Comment:
Fixed in 3e09720e670. The existing MV-only reset is now applied before the
second and later StmtExecutor.queryRetry planning attempts and before the
second and later InsertIntoTableCommand planning attempts. The query retry test
proves mvCanRewritePartitionsMap changes from {p1,p2} to {p1} through
putIfAbsent, and the INSERT retry test verifies stale MV planning state is
absent at the next attempt. The focused FE UT set passed 45/45, and the final
two new retry tests passed 2/2.
##########
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:
Thanks for pointing this out. This PR is intentionally scoped to partition
and materialized-view planning state. tables and oneLevelTables are generic
prepared-statement table-resolution caches, and a complete reset also needs
dedicated coverage for related non-MV paths. I will keep them out of this PR
and address the generic table-cache lifecycle in a separate PR.
##########
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:
Thanks. This PR intentionally removes only UseMvHint because it is part of
the materialized-view rewrite lifecycle. Leading, Ordered, and
USE_CBO_RULE/NO_USE_CBO_RULE are generic planner-hint state. I will not broaden
this MV-focused fix to reset or deduplicate them; that lifecycle will be
handled in a separate PR with dedicated tests.
--
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]
