Add doc values range filtering benchmark tasks

[sgup432]

There has been a lot of interesting work going on making range filter queries faster with doc values. Ideally, range filtering works best with BKD as it can quickly filter out the irrelevant branches and give the desired docs in specific range. Also lucene has IndexOrDocValuesQuery which decides based on cost, on what path to choose.

This PR tries to add benchmarks for range filtering case by using doc values only. I feel it would be useful to track this separately considering the work that has been going in lucene around this area, and we can catch any regressions if they were introduced?

I have added single field filter queries using doc values(skip index enabled) and with different cases - narrow and wide.
Also with some real world pattern like: find documents matching a term AND within a date range. Tests interaction of inverted index + DV skip index.`

Related issue- #549. Though this was focussed on multi field range filter usecase, for now this PR only covers single field.

Let me know if adding this makes sense.

[romseygeek]

I was just going to start working on this myself, thanks @sgup432 :). LGTM, but we should check with @mikemccand about adding more tasks to the default nightly set as IIRC there was some worry that these were starting to take too long to run every 24 hours.

[mikemccand]

I was just going to start working on this myself, thanks @sgup432 :). LGTM, but we should check with @mikemccand about adding more tasks to the default nightly set as IIRC there was some worry that these were starting to take too long to run every 24 hours.

Feel free to add more wikinightly.tasks! I will build faster box or optimize things eventually :) We can't let that hold up improving bench coverage!

[sgup432]

@mikemccand Do you mind taking a look at this again?

[mikemccand]

Thank you I'll have a look!

[sgup432]

Looking at wikinightly.tasks, there are close to 100 task categories and around 500 unique queries expected to run every night, and we'll keep adding more. Even with optimizations, we still run into risks of the total runtime going beyond 24 hours?

I wonder if we should plan to break this monolith file into different sub files based on the usecase.

For example, less volatile tasks(like fuzzy maybe?) can go into a different file like wikinightly-extended.tasks which can be run every 3rd night or so.
And the core tasks around boolean, DV, range, KNN can remain inside wikinightly-core.tasks which would be run nightly.

And then a wikinightly-weekly.tasks file which will contain everything, and runs every weekend.

Also, would it be worth reducing jvmCount from 20 to 10? @mikemccand I know you're working on building a faster box, but should we consider above approach as well?

[mikemccand]

Looking at wikinightly.tasks, there are close to 100 task categories and around 500 unique queries expected to run every night, and we'll keep adding more. Even with optimizations, we still run into risks of the total runtime going beyond 24 hours?

I wonder if we should plan to break this monolith file into different sub files based on the usecase.

For example, less volatile tasks(like fuzzy maybe?) can go into a different file like wikinightly-extended.tasks which can be run every 3rd night or so. And the core tasks around boolean, DV, range, KNN can remain inside wikinightly-core.tasks which would be run nightly.

And then a wikinightly-weekly.tasks file which will contain everything, and runs every weekend.

Whoa, I love that idea! Maybe open spinoff issue for it -- give it its own identity?

Also, would it be worth reducing jvmCount from 20 to 10?

That's also a great idea, and would be a substantial speedup. The tradeoff is more noise, but since each night (or three nights, or seven) we see a series as a bunch of repeated data points, that effectively stacks up the iterations and we get better visibility of the noise over time, and as long as signal (a real change in performance) is rare, that noise is visible without so many non-visible iterations each night.

In fact, maybe we should fix the benchy to plot all 10 or 20 results on each night? Then we could visualize that variance, instead or in addition to the shaded variance bars we have today? I like sending more information to our eyes -- our visual system is insanely powerful/concurrent so we should utilize all that concurrency.

@mikemccand I know you're working on building a faster box, but should we consider above approach as well?

+1, thank you! And I'm not quite working on it yet ... thinking about it really.

[mikemccand]

In fact, maybe we should fix the benchy to plot all 10 or 20 results on each night? Then we could visualize that variance, instead or in addition to the shaded variance bars we have today? I like sending more information to our eyes -- our visual system is insanely powerful/concurrent so we should utilize all that concurrency.

OK I opened #598 to explore this!

[sgup432]

Whoa, I love that idea! Maybe open spinoff issue for it -- give it its own identity?

Yeah I already create a spinoff for this one here - #594