-
Notifications
You must be signed in to change notification settings - Fork 475
switch to traces_sampling_new table #9158
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
Conversation
|
SpennyNDaJets
left a comment
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.
LGTM
## Summary - from perf testing, new table performs comparably to both old use cases - new table requires querying by `Timestamp` and `farmHash64(TraceId)` to be performant - for now, timestamp filter is just +/- 1 hour of the current span - can make this logic smarter in the future if necessary <!-- Ideally, there is an attached GitHub issue that will describe the "why". If relevant, use this section to call out any additional information you'd like to _highlight_ to the reviewer. --> ## How did you test this change? - clicktested locally for traces metrics and single trace view <!-- Frontend - Leave a screencast or a screenshot to visually describe the changes. --> ## Are there any deployment considerations? - will monitor perf in prod after deploying - can revert if issues <!-- Backend - Do we need to consider migrations or backfilling data? --> ## Does this work require review from our design team? - no <!-- Request review from julian-highlight / our design team -->
Summary
TimestampandfarmHash64(TraceId)to be performantHow did you test this change?
Are there any deployment considerations?
Does this work require review from our design team?