[
https://issues.apache.org/jira/browse/LUCENE-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942061#comment-16942061
]
Atri Sharma commented on LUCENE-8213:
-------------------------------------
[~ivera], I am not referring to the LatLonShape failure – I agree with you
that the test should be fine even with async caching since it directly checks
the result count.
However, for testMinSegmentSizePredicate, the failing assertion is on the
cache's cache count – which is directly dependent on the race between the call
and the completion of the async load (as the count is incremented only when the
async load completes).
Hence, for testMinSegmentSizePredicate, the correct fix would be to retry the
check a few times before marking a test failure. WDYT?
> Cache costly subqueries asynchronously
> --------------------------------------
>
> Key: LUCENE-8213
> URL: https://issues.apache.org/jira/browse/LUCENE-8213
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/query/scoring
> Affects Versions: 7.2.1
> Reporter: Amir Hadadi
> Priority: Minor
> Labels: performance
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> IndexOrDocValuesQuery allows to combine costly range queries with a selective
> lead iterator in an optimized way. However, the range query at some point
> gets cached by a querying thread in LRUQueryCache, which negates the
> optimization of IndexOrDocValuesQuery for that specific query.
> It would be nice to see an asynchronous caching implementation in such cases,
> so that queries involving IndexOrDocValuesQuery would have consistent
> performance characteristics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
