-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[Enhancement] support incremental scan ranges deployment at BE side #50254
[Enhancement] support incremental scan ranges deployment at BE side #50254
Conversation
53247b4
to
1a73d07
Compare
e370b23
to
b63725d
Compare
979281a
to
fa031db
Compare
fa031db
to
e6dbb21
Compare
for (const auto& scan_range : scan_ranges) { | ||
if (scan_range.__isset.empty && scan_range.empty) { | ||
if (scan_range.__isset.has_more) { | ||
*has_more_morsel = scan_range.has_more; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
has_more only used for empt scan range? if scan_range not set empty, has_more will be false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes.
[[maybe_unused]] bool has_more_morsel = false; | ||
pipeline::ScanMorsel::build_scan_morsels(node_id, scan_ranges, accept_empty_scan_ranges(), &morsels, | ||
&has_more_morsel); | ||
DCHECK(has_more_morsel == false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
always false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for current implementation, yes.
because only connector_scan_node.cpp supports incremental scan ranges delivery.
67e525e
to
7850906
Compare
Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
-e Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
Signed-off-by: yanz <[email protected]>
7850906
to
9cf1665
Compare
Quality Gate passedIssues Measures |
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[BE Incremental Coverage Report]❌ fail : 22 / 79 (27.85%) file detail
|
[FE Incremental Coverage Report]✅ pass : 43 / 46 (93.48%) file detail
|
Why I'm doing:
What I'm doing:
Compared to the FE modification, the BE modification is simpler, after receiving the request for incremental scan ranges
Fixes #50196
benchmark
sf100
default with file cache
no file cache
sf1000
default with file cache
no file cache
conclusion
comparing to default conf, X=10 increases about 10% latency, but X=50/100/500 does not add latency at all.
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: