Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #345 +/- ##
==========================================
+ Coverage 71.29% 71.57% +0.28%
==========================================
Files 206 206
Lines 15156 15290 +134
==========================================
+ Hits 10805 10944 +139
+ Misses 3565 3560 -5
Partials 786 786 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
# Conflicts: # frac/processor/aggregator.go # node/bench_test.go # node/node_and.go
# Conflicts: # frac/processor/aggregator.go # frac/processor/aggregator_test.go # frac/sealed/lids/iterator_asc.go # frac/sealed/lids/iterator_desc.go # node/lid.go # node/node.go # node/node_and.go # node/node_nand.go # node/node_or.go # node/node_range.go # node/node_static.go # node/node_test.go # node/sourced_node_wrapper.go
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
🔴 Performance DegradationSome benchmarks have degraded compared to the previous run. Show table
|
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 and search request (and even tokens). If we can skip a lot, then there is a lot of improvement.
For example,
service:X AND level:3speeds up by 60% whenlevel:3is used, and speeds up only by 6% whenlevel:4is used as second predicate. Because we reduce total number of results withlevel:3by a lot, while almost all service logs haslevel:4.The performance improvement on typical user aggregation is good, since we skip a lot in agg tree.
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 an 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