-
Notifications
You must be signed in to change notification settings - Fork 3.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
execstats: fix query level stats calculation #59812
Conversation
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.
Re the testing, you could probably add a public testing function to utils_test.go
that creates a FlowMetadata from specified internal maps. You could create two simple ones (e.g. single processor stats with a dummy kv time) and assert that the result is what you expect.
Reviewed 2 of 2 files at r1, 3 of 6 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @asubiotto and @yuzefovich)
pkg/sql/execstats/traceanalyzer.go, line 113 at r2 (raw file):
// aggregate updates s to include stats from other. func (s *QueryLevelStats) aggregate(other QueryLevelStats) {
If you rebase, I added an Accumulate
method in a recent PR.
Previously, we were using an incorrect map to calculate the contention time. Release note: None
cafb54d
to
7c2b381
Compare
Previously, `GetQueryLevelStats` would incorrectly calculate the query level stats when multiple `FlowMetadata` objects are passed in. That is the case when either sub- or post-queries are present. As a result, we would return the query level stats only for the last FlowMetadata object. This is now fixed by aggregating the query level stats of all FlowMetadata objects. Additionally, this commit does some cleanup - using "Flows" instead of "Flow" for metadata to indicate that multiple flows (that are part of the same physical plan) correspond to a single metadata object (this was a point of confusion to me), as well as some comments wrapping. Release note: None
7c2b381
to
9489754
Compare
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.
Added a simple unit test. I originally thought that we need to inject the stats into the trace and didn't realize we can artificially add component stats directly into the FlowsMetadata objects.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @asubiotto)
pkg/sql/execstats/traceanalyzer.go, line 113 at r2 (raw file):
Previously, asubiotto (Alfonso Subiotto Marqués) wrote…
If you rebase, I added an
Accumulate
method in a recent PR.
Ack.
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.
Reviewed 6 of 6 files at r3, 6 of 6 files at r4.
Reviewable status: complete! 1 of 0 LGTMs obtained
TFTR! bors r+ |
Build succeeded: |
execstats: fix query level contention time calculation
Previously, we were using an incorrect map to calculate the contention
time.
Release note: None
execstats: fix GetQueryLevelStats when sub- and post-queries are present
Previously,
GetQueryLevelStats
would incorrectly calculate the querylevel stats when multiple
FlowMetadata
objects are passed in. That isthe case when either sub- or post-queries are present. As a result, we
would return the query level stats only for the last FlowMetadata
object. This is now fixed by aggregating the query level stats of all
FlowMetadata objects.
However, the test is missing since I don't yet see how to do it. It is
left as a TODO.
Additionally, this commit does some cleanup - using "Flows" instead of
"Flow" for metadata to indicate that multiple flows (that are part of
the same physical plan) correspond to a single metadata object (this was
a point of confusion to me), as well as some comments wrapping.
Release note: None