[
https://issues.apache.org/jira/browse/SOLR-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900156#comment-17900156
]
Chris M. Hostetter commented on SOLR-17570:
-------------------------------------------
{quote}Someone using cursorMark (deep paging) probably doesn't care about
numFound at all, and thus could set minExactCount=0 param.
...
I think it should work this way by default.
{quote}
I'm not very familiar with {{minExactCount}} but i don't see any flaw in your
thinking.
{quote}I see no test with both functionalities together.
{quote}
probably because {{cursorMark}} predates {{minExactCount}} by many years and
wasn't considered when {{minExactCount}} was added?
----
IIUC you're basically saying that if {{cursorMark}} is in use, the _default_
value of {{minExactCount}} should be 0 (instead of {{{}Integer.MAX_VALUE{}}}).
And if people *really* want a true exact count, then (IIUC skimming the code)
they can send {{minExactCount=-1}} .
(Although to be really good about backcompat in the same way we have in the
past for changing defaults like this: the default value of {{minExactCount}}
should be based on _both_ {{cursorMark}} being non-null and luceneMatchVersion
< XXX – where XXX is whatever value is in the defualt configset in the version
of solr where you make this change)
Practically speaking though, i'm not sure how much of an impact this will have
on most people? the docs for {{minExactCount}} say it only impacts searches
where the first sort criteria is `score desc` ... in my experience that's not
very common for {{cursorMark}} usecases.
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
