[
https://issues.apache.org/jira/browse/SOLR-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900193#comment-17900193
]
David Smiley commented on SOLR-17570:
-------------------------------------
RE minExactCount==0: I looked through Solr & Lucene code about minExactCount
and I think it's already pretty efficient; there's nothing to add. In other
words, minExactCount has performance applicability beyond Block-Max WAND, such
as sorting by field, especially a field that is always populated. I walked
through the "films" example data set in a debugger today with a variety of
queries and I was impressed with the optimizations at the Lucene level --
namely LUCENE-9280 which enabled sorting by a field to short-circuit rather
early. But if we need to count all docs, then we'd need to visit potentially
much more docs (all that match the query).
> cursorMark should assume minExactCount=0
> ----------------------------------------
>
> Key: SOLR-17570
> URL: https://issues.apache.org/jira/browse/SOLR-17570
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
>
> Claim: Someone using cursorMark (deep paging) probably doesn't care about
> numFound at all, and thus could set minExactCount=0 param. And if they want
> to know, they either find out on the first page straight away (nextCursorMark
> is absent) or failing that, it could send a query purely to ascertain what
> numFound is if it doesn't want to page to the end.
> I see no test with both functionalities together. I think it should work
> this way by default. I tried this with a quick hack using
> DistribCursorPagingTest and it triggered an assertion in
> {{org.apache.solr.search.SolrIndexSearcher#sortDocSet}} that didn't need to
> be there -- it can be removed. The functionality worked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
