[
https://issues.apache.org/jira/browse/SOLR-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591732#comment-14591732
]
Joel Bernstein commented on SOLR-7689:
--------------------------------------
Ok, this is looking pretty good. New test scenario ensures that cache hit
occurs when the main query is re-written. The reRank Explain is showing up
properly in the debugQuery output.
Running the full test suite now so hope to commit and backport to the 5x branch
shortly.
Thanks [~enashed] for reporting the bug and collaborating on the ticket. Thanks
[[email protected]] for guidance on the rewrite.
> 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,
> 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]
