[
https://issues.apache.org/jira/browse/LUCENE-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-7246:
---------------------------------
Attachment: LUCENE-7246.patch
Here is one way of doing it: it adds a new optional method
DocIdSetIterator.getDocIdSet() that can be used to get back a DocIdSet that can
regenerate the same iterator.
In case this method does not feel right, another option I was thinking about
would be to just specialize the BitSet case with instanceof calls without
adding a method. It would only work in the dense case (I would like to avoid
making IntArrayDocIdSet, which is used in the sparse case, public) but maybe
this is fine since doc id sets that take the most time converting are the dense
ones.
> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --------------------------------------------------------------------------
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case
> with TermsQuery, multi-term queries, point-in-set queries and point range
> queries. We cache them more aggressively because these queries need to
> evaluate all matches on a segment before they can return a Scorer. But this
> can also be dangerous: if there is little reuse, then we keep converting the
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges
> faster in practice so I would not like caching to make them appear slower
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet
> instances when we could just reuse existing instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
