924060929 commented on code in PR #69898:
URL: https://github.com/apache/doris/pull/69898#discussion_r4538657095
##########
fe/fe-core/src/main/java/org/apache/doris/qe/StmtExecutor.java:
##########
@@ -2292,11 +2292,41 @@ public List<Slot> planPrepareStatementSlots() throws
Exception {
}
public List<ResultRow> executeInternalQuery() {
+ return executeInternalQuery(true);
+ }
+
+ public List<ResultRow> executeInternalQueryWithoutAudit() {
+ return executeInternalQuery(false);
+ }
+
+ /** Execute a SELECT used by a SHOW command without changing the SHOW
audit event. */
+ public List<List<String>> executeEmbeddedQuery(LogicalPlan plan) {
+ StatementBase originalStmt = parsedStmt;
+ TUniqueId originalQueryId = context.queryId();
+ String originalSqlHash = context.getSqlHash();
+ boolean wasInternal = context.getState().isInternal();
+ boolean wasQuery = context.getState().isQuery();
+ boolean wasNereids = context.getState().isNereids();
+ try {
+ setParsedStmt(new LogicalPlanAdapter(plan,
context.getStatementContext()));
+ return executeInternalQueryWithoutAudit().stream()
+ .map(ResultRow::getValues).collect(Collectors.toList());
+ } finally {
+ setParsedStmt(originalStmt);
+ context.setQueryId(originalQueryId);
Review Comment:
[P2] Preserve the embedded query's audit-statistics identity when restoring
the SHOW ID
For a filtered SHOW that executes its information_schema SELECT on a BE
(e.g. `SHOW FULL TABLES WHERE Table_type = 'BASE TABLE'`),
`executeInternalQueryCommon()` generates a new query ID and dispatches
fragments under that ID. BE statistics are therefore keyed by the inner ID.
After this restoration, `AuditLogHelper` submits the only remaining event under
the outer SHOW ID, while `getAuditStatisticsBackendIds()` still returns the
inner coordinator's dispatched backends.
`WorkloadRuntimeStatusMgr.haveAllBackendsReportedFinalStatistics()` and its
eventual statistics lookup both use `event.queryId`, so they cannot match those
reports: the event waits until the maximum audit timeout (60 seconds by
default), then loses the BE CPU/memory/scan statistics. The collect-mode loop
also never fills `statisticsForAuditLog` from its batches, so there is no
synchronous fallback for those values.
Could the embedded SELECT keep the outer execution ID, or could the audit
machinery explicitly retain a separate statistics ID while exposing the outer
SHOW ID? Please add a test that reports final BE statistics under the actual
execution ID and verifies the single SHOW event receives them without waiting
for the timeout; the current restoration tests mock out the internal execution
entirely.
--
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]
