Rishavbhattarai commented on issue #68896: URL: https://github.com/apache/doris/issues/68896#issuecomment-6335388761
I'd like to work on this, together with #68895, since the MIN/MAX timeouts there are what keep this loop going. One correction: `huge_table_auto_analyze_interval_in_millis` isn't on master anymore. The only gate is `needAnalyzeColumn`, and a failed job leaves `TableStatsMeta` unchanged, so the table is picked again on the next cycle. Because one failed column task cancels the whole job (`AnalysisJob.taskFailed`), a single slow column re-runs the whole table every time. Proposal: on the master, keep a per-table failure record in `AnalysisManager` (last failure time and consecutive failures), for SYSTEM jobs only. `StatisticsAutoCollector.processOneJob` skips the table until `min(base * 2^(n-1), auto_analyze_interval_seconds)` has passed. A success clears the record. The base is a new mutable config, `auto_analyze_failure_backoff_base_seconds` (default 600, 0 turns it off). Unit tests in `AnalysisManagerTest` and `StatisticsAutoCollectorTest`. Two questions: is in-memory state OK, or should it be persisted in `TableStatsMeta` so it survives a master switch? And should I rebase on #69028 first, since it also touches `AnalysisManager`/`TableStatsMeta`? @englefly @morrySnow -- 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]
