-
Notifications
You must be signed in to change notification settings - Fork 832
Move regex opt to after lookup #2973
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
Hrm, not such a big change, interesting but still worth having imo. |
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
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.
Is it worth a CHANGELOG entry? If so, could you rebase master
and add the CHANGELOG entry, please?
pkg/chunk/chunk_store.go
Outdated
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.
Several comments here:
- Nit:
if
condition can be merged into singleif
statement. - No unit test covers
continue
branch. I think we should cover it by tests. - If
labelValue
is one of matched values, we still run regex on it on the next line. We can removematcher.Matches
in this case, and save some cpu cycles.
This looks useful, and would be great to merge. @gouthamve would you find some time to look at the comments and get the PR into mergeable state? |
49a7cb6
to
8e64367
Compare
fixes cortexproject#2906 When we use the caching client (which is what is used in most cases), we load the entire row (tableName+HashKey) irrespective of what the rangeKey parameters are. Which means with the optimisation, we are loading the same row multiple times and then operating on the same data. This PR moves the optimisation to after the data is loaded which should be faster. Signed-off-by: Goutham Veeramachaneni <[email protected]>
Signed-off-by: Goutham Veeramachaneni <[email protected]>
Signed-off-by: Goutham Veeramachaneni <[email protected]>
Signed-off-by: Goutham Veeramachaneni <[email protected]>
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, thanks!
fixes #2906
When we use the caching client (which is what is used in most cases), we
load the entire row (tableName+HashKey) irrespective of what the
rangeKey parameters are. Which means with the optimisation, we are
loading the same row multiple times and then operating on the same data.
This PR moves the optimisation to after the data is loaded which should
be faster.
Signed-off-by: Goutham Veeramachaneni [email protected]
What this PR does:
Which issue(s) this PR fixes:
Fixes #
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]