ok when my head is cooled down, I remember this old school issue... that I have been dealing with it myself.
so I do not expect this can be straighten out or fixed in anyways. basically when you have to sorted results sets you need to merge, and paginate through, it is never an easy job (if all is possible) to figure out what is exactly the number if you only require a portion of the results being returned. for example if 1 set has 40,000 rows returned, the other set has 50,000 returned, and you want the start=440 and rows=20 (paginate on UI), the typical algorithm will be sort both sets and return the near portion of both sets, toss away the duplicates in that range (20 rows), so even you calcualte with the duplicates prior to that start point, you have no way to tell how many duplicates after that point, so you really do not know for fact the exact / accurate numFound, unless you require return the whole thing. and that is why when I give a huge rows number, it will give me the accurate count each time. However, solr shard query will throw 500 server error if the returned set is around 50k, which is reasonable. So find work around in the context is the only solution. Check with google search pattern, may get some fuzzy idea :-) thanks jie -- View this message in context: http://lucene.472066.n3.nabble.com/numFound-changes-on-changing-start-and-rows-tp3999752p4061633.html Sent from the Solr - User mailing list archive at Nabble.com.
