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

Joel Bernstein commented on SOLR-7689:
--------------------------------------

Ok I see the issue you're taking about with the rewrittenQuery. I believe it 
doesn't apply to the boostedPriority because that won't get regenerated during 
autowarming. I'll verify this.

The normal pattern is a little different here because we need to return the 
re-written query wrapped in a ReRankQuery in order to preserver the re-rank 
Explain. Otherwise we could just return the mainQuery and let that get 
rewritten. I'll work on a patch that returns a clone of the ReRankedQuery 
wrapped around the rewritten query. The only trick to this is that the cloned 
ReRankQuery will also have rewrite() called on it because of the loop in 
IndexSearcher.rewrite(). So the cloned ReRankQuery will need to return itself 
from the rewrite method, rather then cloning again in an endless loop.

> ReRankQuery rewrite method can change the QueryResultKey causing cache misses.
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-7689
>                 URL: https://issues.apache.org/jira/browse/SOLR-7689
>             Project: Solr
>          Issue Type: Bug
>          Components: search, SearchComponents - other
>            Reporter: Emad Nashed
>            Assignee: Joel Bernstein
>         Attachments: SOLR-7689.patch, SOLR-7689.patch, SOLR-7689.patch
>
>
> In SolrIndexSearcher class, the key used to lookup results in 
> queryResultCache uses the original query. 
> However later in createNormalizedWeight the query gets re-written, and then 
> saved in the queryResultCache after it's re-written. 
> This causes cache misses for the same query, and un-necessary inserts in the 
> queryResultCache.
> I can reproduce this using a re-ranking query that is using a main query as a 
> dismax query, the dismax Query could be re-written into a TermQuery, which 
> makes sense, but will cause cache misses.
> I tested a quick solution by just using q.clone()  when it comes to build 
> QueryResultKey, and it works fine, but not sure if that is the best way of 
> doing it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to