[jira] [Assigned] (SOLR-10732) potential optimizations in callers of SolrIndexSearcher.numDocs when docset is empty

["Munendra S N (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Munendra S N reassigned SOLR-10732:
-----------------------------------

    Assignee: Munendra S N

> potential optimizations in callers of SolrIndexSearcher.numDocs when docset is empty
> ------------------------------------------------------------------------------------
>
>                 Key: SOLR-10732
>                 URL: https://issues.apache.org/jira/browse/SOLR-10732
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Chris M. Hostetter
>            Assignee: Munendra S N
>            Priority: Major
>         Attachments: SOLR-10732.patch, SOLR-10732.patch
>
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> spin off of SOLR-10727...
> {quote}
> ...why not (also) optimize it slightly higher up and completely avoid the construction of the Query objects? (and in some cases: additional overhead)
> for example: the first usage of {{SolrIndexSearcher.numDocs(Query,DocSet)}} i found was {{RangeFacetProcessor.rangeCount(DocSet subset,...)}} ... if the first line of that method was {{if (0 == subset.size()) return 0}} then we'd not only optimize away the SolrIndexSearcher hit, but also fetching the SchemaField & building the range query (not to mention the much more expensive {{getGroupedFacetQueryCount}} in the grouping case)
> At a glance, most other callers of {{SolrIndexSearcher.numDocs(Query,DocSet)}} could be trivially optimize this way as well -- at a minimum to eliminate Query parsing/construction.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org