-
Notifications
You must be signed in to change notification settings - Fork 9.7k
storage: pass limit param as hint in querier #14109
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
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.
Thanks for this.
AFAIU, the limit hint isn't taken into account by the mergeGenericQuerier
implementation e.g.
For the Select
it's not that important as it streams, but we'll need that for the labels fcts.
We could create an issue for that and address it in another PR.
After this is in place, we could also make use of that limit hint for |
09dc94f
to
d3f5bae
Compare
@machine424 - Sorry, I didn't understand how the sample limit is relevant here. Could you elaborate more? |
Hey @bboreham, could you please take a look at this PR? |
We can, later, set the limit hint here prometheus/storage/remote/read_handler.go Lines 147 to 161 in 1081e33
h.remoteReadSampleLimit if it makes sense.
You can rebase as #14116 was merged. |
d3f5bae
to
1edec91
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.
If I read this correctly you didn't implement early exit when the limit was hit; just added the interface so that someone else could do that.
This seems wrong to me; if we're going to add this complexity we should make Prometheus better too.
I was afraid that including this change in this PR would make it big. I will create another PR soon after this to implement those changes. |
9b7dd3e
to
0057a07
Compare
Yes, we discussed that for |
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 so far, just some nits.
0057a07
to
00e966a
Compare
00e966a
to
403214b
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.
thanks again!
looking forward to the implementation PR.
Let's see if it's ok for Bryan as well.
9b9d037
to
edc8d0e
Compare
edc8d0e
to
4ca2212
Compare
I took a stab at implementing the limits inside merge.go |
I'd proceed as we agreed: merge the PR with the interface changes only (I already approved those) if no one has an objection, and then add the implementation in another PR. This will also keep reviewing easy. |
14b8811
to
4a46dcf
Compare
I reverted back to the original. I can create a separate PR for the implementation. :) |
Signed-off-by: 🌲 Harry 🌊 John 🏔 <johrry@amazon.com>
4a46dcf
to
d5f6887
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.
lgtm, Let's see if it's ok for Bryan.
f251e35
to
d5f6887
Compare
Could this PR be merged if there are no objections? |
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.
Thanks!
Related Issues
Description
In #13396 a new limit param for the series, label names and label values APIs was introduced. This limit is currently only applied in the api.go. The storage implementations that do not support streaming such as Thanos, Cortex etc, will not be able to receive the limit param and would have to return all the results.
This change would pass the limit param as hints to storage so that the implementations can use that to return only the required number of results.