Fix the incorrect ordering for topk and bottomk in shardable queries #5170
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
topk
orbottomk
, the response will be concatenated without a global sort.sort
orsort_desc
, the response will be sorted by values.Examples:
1 + sort(sum by (code) (http_requests_total) )
sort(topk by (code) (10, http_requests_total))
topk by (code) (10, http_requests_total)
topk(5, http_requests_total) by (code) + sort(http_requests_total)
sort(http_requests_total) + topk(5, http_requests_total) by (code)
There is discrepancy for case 4 where Prometheus doesn't sort the responses but Thanos will sort by value.
I believe the above approach will give reasonable compatibility with Prometheus without increasing the complexity in the merging logic in the frontend.
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]