[
https://issues.apache.org/jira/browse/SOLR-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900169#comment-17900169
]
David Smiley commented on SOLR-17570:
-------------------------------------
Thanks for your input.
Unfortunately I think we have no way to completely disable numFound. If
minExactCount is 0, this is our only way to basically convey that in a
round-about way; do you agree? We could further optimize for the "0" case to
not compute numFound, which should have some performance implications greater
than Block-Max WAND. That deserves another JIRA! Doing now and will link.
BTW a use-case I'm exploring at work is one where the security visibility of
documents must be post-filtered by the client. If you are interested in
learning more, DM me to have a virtual 1:1 with you over a beer/coffee to share
this nightmare with you :-)
> 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
