englefly commented on code in PR #68282:
URL: https://github.com/apache/doris/pull/68282#discussion_r4078460518
##########
fe/fe-core/src/main/java/org/apache/doris/statistics/analysis/TableStatsMeta.java:
##########
@@ -195,6 +255,15 @@ public void update(AnalysisInfo analyzedJob, TableIf
tableIf) {
if (tableIf instanceof OlapTable) {
OlapTable olapTable = (OlapTable) tableIf;
indexesRowCount.putAll(analyzedJob.indexesRowCount);
+ // The collected row count above already includes the rows
which had been loaded when the
+ // job was built, remember how many they were, they are not
delta rows. The baseline may
+ // only advance together with the collected base index row
count, an analysis of another
+ // index (a materialized view) doesn't touch it.
+ // Statistics supplied by the user are not collected from the
table, they carry no baseline.
+ if (!analyzedJob.userInject
Review Comment:
Fixed in 4879cc295ea, and your sequential reproduction is what the added
test walks through.
Confirmed the mechanism, including the numbers: the injection replaces
`indexesRowCount` of the base index
while the baseline stayed where the previous analysis (or the reset) left
it, and `DROP STATS t(c)` clears
`userInjected` in `invalidateLocalStats()` without clearing either value, so
after TRUNCATE -> load N ->
inject N -> drop, `getOlapTableRowCount()` returned `N + (N - 0) = 2N`.
Fix, coupling the count and its baseline as you suggested: when a job
supplies the row count of the base
index, the baseline moves to the current `updatedRows`, because such a row
count describes the table as of
now, so the rows loaded so far are part of it.
```java
if (analyzedJob.indexesRowCount.containsKey(olapTable.getBaseIndexId())) {
// A row count supplied by the user replaces the collected one and
describes the table as of now, so
// the rows loaded so far are part of it and the baseline has to move to
the current value. Keeping
// the older baseline would count those rows again once DROP STATS
clears userInjected.
updatedRowsBase.set(analyzedJob.userInject ? updatedRows.get() :
analyzedJob.updateRows);
}
```
A job which collected another index still cannot move the baseline of the
base index, and a row count
supplied for another index is ignored for it as before.
Coverage added:
`TableStatsMetaTest.testDeltaRowCountOfInjectedRowCountAfterDropStats` walks
exactly the
lifecycle you described (reset of a truncation -> load -> injection ->
clearing `userInjected` as
`DROP STATS` does) and asserts that the record reports N, not 2N, both while
the injected count applies and
after the flag is cleared.
The branch is also rebased onto the current master (776d8758b0c) and the
full FE build, the unit tests and
both regression suites were re-run on the rebased revision.
--
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]
