Open
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #345 +/- ##
==========================================
+ Coverage 71.52% 71.77% +0.25%
==========================================
Files 204 205 +1
Lines 14812 14978 +166
==========================================
+ Hits 10594 10751 +157
- Misses 3454 3459 +5
- Partials 764 768 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
2 tasks
ea92b83 to
7de3263
Compare
Member
Author
|
@seqbenchbot up 0-fast-cmp-xor search-logbench |
|
Nice, @cheb0 The benchmark with identificator Show summary
Have a great time! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
# Conflicts: # node/cmp_lid.go # node/node.go # node/node_and.go # node/node_or.go # node/node_static.go
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
A new operation which boosts search and aggregation performance. It's implemented on top of faster cmp branch because fast compares are vital for this operation. It's also a base for future improvements like skipping disk reads.
Currently,
NextGeqworks more like a hint - some nodes do not support it andNextGeqbehaviour is same asNext. Therefore, some operations still have loops even when callingNextGeq(i.e. scrolling past lower values), like in aggregator.go. Might be improved in future.Measurements
Performance improvement depends on a particular operation. Search performance benefit varies, but mostly it's mediocre.
The performance improvement on typical user aggregation is good.
service:xyz | group by k8s_pod count(*) (prod fracs)
master:
370-456 ms(hot-cold)fast cmp:
320-402 msnext geq:
73-153 ms(-50-70%)There are also downsides. It's not zero-cost. For example, the case when we iterate the whole tree and there is nothing to skip (i.e. we traverse exactly same paths but there is extra comparison in
NextGeqoperation) :exists:service | group by k8d_pod count(*)
master:
690-821 msfast cmp:
600-730 msnext geq:
662-800 ms(+10% skipping overhead)However, thanks to faster cmp, it will still be faster than current main branch, i.e. there is no performance downgrade. The next steps are probably to implement some sort of cost based planning (and cardinality estimation) where we can evaluate if there is a skipping potential and disable it altogether, or maybe even avoid constructing an aggregation tree.
Fixes #332