[
https://issues.apache.org/jira/browse/SOLR-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588811#comment-14588811
]
Joel Bernstein commented on SOLR-7689:
--------------------------------------
Yeah this is special case. The ReRankQuery is just a wrapper that peels off on
the rewrite() method. The wrapper stays on in the SolrIndexSearcher to set the
topdocs collecter and act as the cache key. In the Lucene IndexSearcher
search() method where rewrite() is called, all it needs to do is return the
mainQuery. The rewrite method in the Lucene IndexSearcher does a nifty little
loop that ensures the main query then gets rewritten.
> 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
>
>
> 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]
