sql: expose the number of BatchRequests issued by the fetchers #83365
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change is |
yuzefovich
force-pushed
the
count-br
branch
2 times, most recently
from
2a48a49 to
fa15748
Compare
cucaroach
approved these changes
Jun 28, 2022
There was a problem hiding this comment.
Reviewed 2 of 2 files at r1, 32 of 32 files at r2, all commit messages.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @michae2)
Given the recent cleanup of lifecycles of different fetcher objects, we can simplify the way we track the number of bytes read by the cFetcher. Previously, when the cFetcher was used for the index joins, we would call `StartScanFrom` which would re-create the underlying KVFetcher, but now a single object is used throughout the whole operation, so we can just ask it directly for this statistic. We still close the cFetcher eagerly in some cases, so we still need to store the statistic explicitly in such cases. Release note: None
This commit teaches `row.KVFetcher` to track the number of BatchRequests issued to perform the reads and then exposes this information along side other execution statistics like the number of bytes read. I imagine that this can be handy in some cases, but even more so with the increased usage of the streamer. Release note (sql change): A new execution statistic that tracks the number of gRPC calls issued to perform the read operations has been added to EXPLAIN ANALYZE output. It exposes low-level details that might aid with debugging the performance of queries for power users.
yuzefovich
commented
Jun 28, 2022
There was a problem hiding this comment.
Rebased to resolve the merge conflict.
TFTR!
bors r+
Reviewable status:
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
bors r+ |
|
Already running a review |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
colfetcher: simplify tracking the number of bytes read
Given the recent cleanup of lifecycles of different fetcher objects, we
can simplify the way we track the number of bytes read by the cFetcher.
Previously, when the cFetcher was used for the index joins, we would
call
StartScanFromwhich would re-create the underlying KVFetcher, butnow a single object is used throughout the whole operation, so we can
just ask it directly for this statistic. We still close the cFetcher
eagerly in some cases, so we still need to store the statistic
explicitly in such cases.
Release note: None
sql: expose the number of BatchRequests issued by the fetchers
This commit teaches
row.KVFetcherto track the number of BatchRequestsissued to perform the reads and then exposes this information along side
other execution statistics like the number of bytes read. I imagine that
this can be handy in some cases, but even more so with the increased
usage of the streamer.
Fixes: #81998.
Addresses: #82156.
Release note (sql change): A new execution statistic that tracks the
number of gRPC calls issued to perform the read operations has been
added to EXPLAIN ANALYZE output. It exposes low-level details that might
aid with debugging the performance of queries for power users.