[
https://issues.apache.org/jira/browse/SOLR-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246305#comment-17246305
]
Munendra S N commented on SOLR-10732:
-------------------------------------
{quote}I'm curious, Munendra S N – were you able to perceive a performance
benefit with these changes? Where these optimizations are located, afaict they
optimize edge cases, and the query-building they prevent (if I'm reading right)
is generally pretty lightweight (e.g., TermQuery ...).{quote}
Changes here are based on this
[comment|https://issues.apache.org/jira/browse/SOLR-10727?focusedCommentId=16020247&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16020247].
As you said, this tries to avoid additional object creation and computation
for some edge cases and based on my understanding, it helps especially in case
facet queries or group facets
{quote}By way of contrast (wrt complexity/benefit tradeoff), at the leaf level
it looks like SolrIndexSearcher.getDocSet(Query, DocSet) could be optimized in
a way analogous to what SOLR-10727 does for SolrIndexSearcher.numDocs(Query,
DocSet), avoiding filterCache pollution {quote}
+1, If there is possibility to improve/optimize it. We should definitely do it
but I think it should be handled in its own issue
{quote}or maybe also 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). The changes here seem to be building in mid-level "shot in the dark"
safeguards, where it's relatively unclear what's going on.{quote}
Initially, planned to make these changes in getFacetCounts which would handle
the case for intervalFacet and heatmap but realized changes would be too
cluttered so, decided to delegate handling this case respective types. Let me
know if this could be simplified and probably handle other facets too
> 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
