Can we improve caching of dense results?
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
I am working into improving the behaviour of DocValues skippers when they are applied to a single value, dense field that is the primary sort of an index. In this case, for some queries we know the result is dense so we can just find the minimum and maximum document of the result and create a DocIdSetIterator using `DocIdSetIterator.range(minDocID, maxDocID)`. This is the denser representation you can have for this type of iterator.
The issue I am seeing is that if this iterator get cached it looses the density and potentially can be cached as a FixedBitSet. This feels pretty wasteful and in addition it looses some characteristics, for example if cached as a RoaringDocIdSet, then the iterator produced does not implement #docIdRunEnd so you need to iterate one document at a time.
I cannot see a way to detect a scorer is dense so I wonder if someone has suggestions on how to improve this case. Maybe we should not cache such queries although caching still helps here.
Contributor guide
Research direction
Start by tracing the DocValues skipper path for dense, single-value fields and how its DocIdSetIterator is passed into the query cache. Compare the dense range iterator with FixedBitSet and RoaringDocIdSet behavior, especially docIdRunEnd. Done means reaching a clear caching design that preserves dense-result characteristics or documents why such results should not be cached.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- search
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100