[
https://issues.apache.org/jira/browse/LUCENE-10120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437288#comment-17437288
]
Lu Xugang commented on LUCENE-10120:
------------------------------------
{quote}Or is the idea that we create a FixedBitSet, but discard it and instead
return this optimized CacheAndCount implementation if all criteria are met
(i.e. all docs within a range match){quote}
That's what I think. if lucky enough, docId was collected sequential and
ordered, then we could never create a FixedBitSet, thought it is not a common
case especially indexSort is enabling.
So in most case, we still need to create a *FixedBitSet*, but recording maxDoc
and minDoc at the same time. Finally, if *FixedBitSet#cardinality()* equals
(maxDoc - minDoc + 1), it means set of docIds is sequential, then we could
discard *FixedBitSet* and use a new *DocIdSet*（called RangeDocIdSet present in
PR） which only contains maxDoc and minDoc.
> Lazy initialize FixedBitSet in LRUQueryCache
> --------------------------------------------
>
> Key: LUCENE-10120
> URL: https://issues.apache.org/jira/browse/LUCENE-10120
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Affects Versions: main (9.0)
> Reporter: Lu Xugang
> Priority: Major
> Attachments: 1.png
>
>
> Basing on the implement of collecting docIds in DocsWithFieldSet, may be we
> could do similar way to cache docIdSet in
> *LRUQueryCache#cacheIntoBitSet(BulkScorer scorer, int maxDoc)* when docIdSet
> is density.
> In this way , we do not always init a huge FixedBitSet which sometime is not
> necessary when maxDoc is large
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
