[ https://issues.apache.org/jira/browse/SOLR-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588197#comment-14588197 ]
Joel Bernstein commented on SOLR-7689: -------------------------------------- Not seeing a problem with the boostedPriority Map. This is map is created by the main execution thread in the QueryElevationComponent and is only used for a specific query. So each query should have a unique HashMap. Once it's created I believe it's read only. The code is pretty confusing though because of the callback to QueryElelvationComponent. This should probably be looked at. > QueryResultKey saved in cache uses the query after rewrite which causes 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 > > 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