[
https://issues.apache.org/jira/browse/SOLR-11595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247641#comment-16247641
]
David Smiley commented on SOLR-11595:
-------------------------------------
Rob, I'm not adding a cache here. SolrIndexSearcher _already_ uses a
SlowCompositeReaderWrapper. I simply propose we use it in
localCollectionStatistics(). Also, the design choices are different between
Lucene IndexSearcher and Solr's SolrIndexSearcher. As you know, this is where
Solr puts most of it's caches.
> optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields
> ------------------------------------------------------------------------------
>
> Key: SOLR-11595
> URL: https://issues.apache.org/jira/browse/SOLR-11595
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Fix For: 7.2
>
> Attachments:
> SOLR_11595_optimize_SolrIndexSearcher_collectionStatistics.patch
>
>
> {{SolrIndexSearcher.localCollectionStatistics(field)}} simply calls Lucene's
> {{IndexSearcher.collectionStatistics(field)}} which in turn calls
> {{MultiFields.getTerms(reader, field)}}. Profiling in an app with many 150
> fields in the query shows that building the MultiTerms here is expensive.
> Fortunately it turns out that Solr already has a cached instance via
> {{SlowCompositeReaderWrapper}} (using MultiFields which has a
> ConcurrentHashMap to the MultiTerms keyed by field String.
> Perhaps this should be improved on the Lucene side... not sure. But here on
> the Solr side, the solution is straight-forward.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
