[
https://issues.apache.org/jira/browse/SOLR-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248077#comment-17248077
]
Michael Gibney commented on SOLR-10732:
---------------------------------------
Thanks, [~munendrasn], that makes sense. I don't have any objections, and your
change is straightforward and low-risk.
Following up on my comment about optimizing "higher up in the program logic, to
prune as much execution as possible (and when it's clearer how/why we got the
point of having an empty domain)", I started trying to approach this from the
top down and quickly got rather deeper into it than I'd intended. I'll post the
resulting patch here for the sake of comparison; feel free to incorporate any
aspects as you see fit, but to be clear I think it'd be perfectly reasonable to
go ahead with your initial patch.
The new patch optimizes wrt configured {{mincount}} (where applicable) and
covers all legacy facet types (I think). It's still pretty straightforward, but
compared to your initial proposal it's admittedly more complex. It prunes
potentially quite a bit more execution I think; but notably, as a consequence
of optimizing higher up, and wrt {{mincount}} (as opposed to only
{{domain.size()==0}}), it carries potential risks that your patch doesn't.
(also note: it will fail precommit due to some {{nocommit}} comments on some
assertions temporarily present to check for functional parity with your initial
patch).
> 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
> Priority: Major
> Attachments: 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
