-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
sql: emit more tracing events from the stats cache #54035
sql: emit more tracing events from the stats cache #54035
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.
Reviewed 1 of 1 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @RaduBerinde)
pkg/sql/stats/stats_cache.go, line 192 at r1 (raw file):
// We are in the process of grabbing stats for this table. Wait until // that is complete, at which point e.stats will be populated. log.VEventf(ctx, 1, "waiting for statistics for table %d", tableID)
So the difference here is that we're always logging somewhere, but the location depends on the verbosity?
pkg/sql/stats/stats_cache.go, line 309 at r1 (raw file):
log.VEventf(ctx, 1, "refreshing statistics for table %d", tableID) ctx, span := tracing.ForkCtxSpan(ctx, "refresh-table-stats") defer tracing.FinishSpan(span)
Will this wait to finish until the goroutine below finishes?
The stats cache has various "slow" paths (where we need to query the system table). These are currently only logged if verbosity is high. This change switches to `VEvent` in most cases, so that these are visible during tracing (including in statement diagnostics bundles). This will allow us to diagnose slow planning times, e.g. due to the stats cache getting full. Release justification: low-risk change to existing functionality, high potential benefit for debugging issues. Release note: None
Add a few more tracing events around the use of the optimizer. Release note: None
2d41695
to
7ea3a55
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.
TFTR! Updated and added a small commit that adds a couple of more events in the planning code.
Reviewable status:
complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @rytaft)
pkg/sql/stats/stats_cache.go, line 192 at r1 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
So the difference here is that we're always logging somewhere, but the location depends on the verbosity?
VEvent generates a trace event if we are tracing, and also logs it if the verbosity is high. The previous code did not generate a trace event if verbosity was not set.
pkg/sql/stats/stats_cache.go, line 309 at r1 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
Will this wait to finish until the goroutine below finishes?
Silly me, fixed. Nice catch! This didn't cause any failures because I don't think we ever have a span in the context currently, but I put it in just in case.
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 1 of 1 files at r2, 1 of 1 files at r3.
Reviewable status:complete! 1 of 0 LGTMs obtained
bors r+ |
Build succeeded: |
The stats cache has various "slow" paths (where we need to query the
system table). These are currently only logged if verbosity is high.
This change switches to
VEvent
in most cases, so that these arevisible during tracing (including in statement diagnostics bundles).
This will allow us to diagnose slow planning times, e.g. due to the
stats cache getting full.
Release justification: low-risk change to existing functionality, high
potential benefit for debugging issues.
Release note: None