[ 
https://issues.apache.org/jira/browse/LUCENE-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940798#comment-16940798
 ] 

Atri Sharma commented on LUCENE-8213:
-------------------------------------

Interesting – I did not realise that testLRUEviction could also cause 
LRUQueryCache to cache asynchronously, hence did not update it to handle the 
same (in the manner testLRUConcurrentLoadAndEviction does).

 

I have pushed a test fix now – beasted the test 50 times with the seed you 
provided, and also beasted the entire TestLRUQueryCache suite 20 times with the 
seed. Ran the entire Lucene test suite – came in clean.

 

It is curious to note that I could not reproduce the test failure without the 
seed even after running multiple times – kudos to the CI!

> 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

Reply via email to