Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Join probe time includes the time of sending result to channel and getting avaliable empty chunk, which makes the probe time distorted #52222

Closed
windtalker opened this issue Mar 29, 2024 · 0 comments · Fixed by #52227
Labels
severity/moderate sig/execution SIG execution type/bug This issue is a bug.

Comments

@windtalker
Copy link
Contributor

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

In explain analyze, if a here is join operator, it will record probe_time which indicates how much times does the probe process takes.

build_hash_table:{total:4.64s, fetch:4.64s, build:0s}, probe:{concurrency:5, total:1m49.5s, max:21.9s, probe:18.9s, fetch:1m30.6s}

However, this probe time actually includes the time of sending results to channel and getting avaliable emtpy chunk

tidb/pkg/executor/join.go

Lines 1074 to 1080 in 8d9e67b

if joinResult.chk.IsFull() {
w.hashJoinCtx.joinResultCh <- joinResult
ok, joinResult = w.getNewJoinResult()
if !ok {
return false, joinResult
}
}

So if the parent operator of join is slow(like high cardinality aggregation), the probe time will be very high, which is distorted and misleading.

2. What did you expect to see? (Required)

3. What did you see instead (Required)

4. What is your TiDB version? (Required)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/moderate sig/execution SIG execution type/bug This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants