Uh oh!
There was an error while loading. Please reload this page.
[improvement](be) Add queue time for delete bitmap tasks - #65248
Conversation
### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: MOW memtable flush calculates delete bitmap asynchronously, but its log did not show how long the async task waited in the executor queue. The load delete-bitmap executor also used the same thread-pool metric name as the normal delete-bitmap executor, making their metrics hard to distinguish. This change records queue time for flush, segment-level, between-segment, and cloud tablet-level async delete-bitmap tasks, and gives the load delete-bitmap executor a distinct thread-pool name. ### Release note None ### Check List (For Author) - Test: - Build: `./build.sh --be -j 100` - Code style: `build-support/check-format.sh` - Behavior changed: No - Does this need documentation: No
hello-stephen
commented
Jul 6, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
bobhan1
commented
Jul 6, 2026
/review |
bobhan1
commented
Jul 6, 2026
run buildall |
There was a problem hiding this comment.
Reviewed PR 65248 against the Doris code-review checkpoints and the BE cloud/storage guides. I did not find a PR-scoped correctness issue that needs an inline comment.
Critical checkpoint conclusions:
- Goal/test proof: the patch achieves the stated observability goal by adding queue-time logging to delete-bitmap async work and separating the load delete-bitmap thread-pool name. The author reports
./build.sh --be -j 100andbuild-support/check-format.sh; I could not rerun build/tests in this runner because.worktree_initialized,thirdparty/installed, andthirdparty/installed/bin/protocare absent. - Scope/focus: the change is small and limited to nine BE storage/cloud files. No additional user-provided review focus points were supplied.
- Concurrency/lifecycle: async task behavior is unchanged apart from capturing
MonotonicMicros()before enqueue and reading the elapsed value inside the worker. Existing token/thread-pool and lock behavior is preserved. - Compatibility/config/session: no storage format, thrift/protocol, config, session variable, or persistence compatibility change was introduced.
- Data correctness and parallel paths: cloud and non-cloud engines both pass distinct executor names; token-based segment and between-segment delete-bitmap paths pass measured queue time, while synchronous/default callers keep
queue_time_us = 0. Delete-bitmap version, sentinel, and update logic is unchanged. - Observability/performance: the added work is a small monotonic timestamp read per submitted task and extra logging fields/log-threshold checks; I did not find a hot-path correctness or lifecycle issue.
- Tests/style: scoped clang-format 16 wrapper check passed for all nine changed files, and scoped
git diff --checkagainst the fetched base/head was clean.
Subagent conclusions:
optimizer-rewrite: no optimizer/Nereids or semantic-equivalence candidate found; final convergence round ended withNO_NEW_VALUABLE_FINDINGS.tests-session-config: no regression-output, session/config, compatibility, or basic CI/style candidate found; final convergence round ended withNO_NEW_VALUABLE_FINDINGS.
hello-stephen
commented
Jul 6, 2026
TPC-H: Total hot run time: 29951 ms |
hello-stephen
commented
Jul 6, 2026
TPC-DS: Total hot run time: 173746 ms |
hello-stephen
commented
Jul 6, 2026
ClickBench: Total hot run time: 25.15 s |
hello-stephen
commented
Jul 6, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 6, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
Problem Summary: MOW memtable flush calculates delete bitmap asynchronously, but its log did not show how long the async task waited in the executor queue. The load delete-bitmap executor also used the same thread-pool metric name as the normal delete-bitmap executor, making their metrics hard to distinguish. This change records queue time for flush, segment-level, between-segment, and cloud tablet-level async delete-bitmap tasks, and gives the load delete-bitmap executor a distinct thread-pool name.
…65523) ### What problem does this PR solve? Issue Number: None Related PR: #65248 Problem Summary: Backport #65248 to branch-4.1. MOW memtable flush calculates delete bitmap asynchronously, but its log did not show how long the task waited in the executor queue. The load delete-bitmap executor also used the same thread-pool metric name as the normal delete-bitmap executor. This change records queue time for flush, segment-level, between-segment, and cloud tablet-level async delete-bitmap tasks, and gives the load delete-bitmap executor a distinct thread-pool name. The branch-4.1 conflict in `beta_rowset_writer.cpp` was resolved while preserving the branch-specific debug point. ### Release note None ### Check List (For Author) - Test - [x] Manual test (add detailed scripts or steps below) - `./build.sh --be -j100` - `build-support/check-format.sh` - Behavior changed: - [x] No. - Does this need documentation? - [x] No. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label
What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: MOW memtable flush calculates delete bitmap asynchronously, but its log did not show how long the async task waited in the executor queue. The load delete-bitmap executor also used the same thread-pool metric name as the normal delete-bitmap executor, making their metrics hard to distinguish. This change records queue time for flush, segment-level, between-segment, and cloud tablet-level async delete-bitmap tasks, and gives the load delete-bitmap executor a distinct thread-pool name.
Release note
None
Check List (For Author)
./build.sh --be -j 100build-support/check-format.sh