[
https://issues.apache.org/jira/browse/SOLR-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589944#comment-14589944
]
Yonik Seeley commented on SOLR-7689:
------------------------------------
As for ReRankQuery.boostedPriority, which is retrieved from the request
context, it seems like it can be safely removed?
It's only used to pass to the collector during creation, and that's also where
it's set.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
