any update on this? will this be addressed/fixed?
in our system, our UI will allow user to paginate through search results. As my in deep test find out, if the rows=0, the results size is consistently the total sum of the documents on all shards regardless there is any duplicates; if the rows is a number larger than the supposedly returned the merge document number, the result numFound is accurate and consistent, however, if the rows is with a number smaller than the supposedly merge results size, it will be non-deterministic. unfortunately, in our system, it is not easy to work around this problem. we have to issue and query whenever use click on Next button, and the rows is 20 in our case and in most of the cases it is smaller than the merged results size, so we get a different number each time. If we do rows=0 up in front, it wont work either, since we want the accurate number and others may have indexed new documents at the same time. Especially when user hit the last page, sometimes we see the numFound off by hundreds, this wont work. please advice. thanks Jie -- View this message in context: http://lucene.472066.n3.nabble.com/numFound-changes-on-changing-start-and-rows-tp3999752p4061628.html Sent from the Solr - User mailing list archive at Nabble.com.