Two more benchmarks for partial sorting with ESQL#703
Two more benchmarks for partial sorting with ESQL#703craigtaverner merged 2 commits intoelastic:masterfrom
Conversation
These cannot be replicated in _search since that only supports what can be pushed down to lucene, and this feature explicitly only pushes down part of the sort, and then does the other part in the compute engine.
| "tags": ["distance", "esql", "sort"] | ||
| }, | ||
| { | ||
| "operation": "distanceSort-esql-partial", |
There was a problem hiding this comment.
For my curiosity, why do we have different warmups and iterations in these new benchmarks and the rationally behind this numbers?
There was a problem hiding this comment.
I chose numbers that are related to the inverse of the latency. So a very long running benchmark (like the 10-20 seconds of the sort before the performance) should have very few iterations (we really don't care about precision on such long queries), while fast benchmarks (10-50ms) usually have high iteration counts, so we can get more stable, and predictable results. But in general I've also started moving away from really high numbers like 200/100 because they do not seem more stable than numbers like 50/50. I think variability is coming from the cloud infrastructure, so high iteration counts are costing time and money without bringing value.
2 participants
These cannot be replicated in _search since that only supports what can be pushed down to lucene, and this feature explicitly only pushes down part of the sort, and then does the other part in the compute engine.