+1, I needed the same. Its often a use case to simply get number of results. And a PQ with one entry and all the logic does not make sense here. We should just count hits.

It would be good if we could have a TotalHitsCollector which just counts total hits (as a standalone Collector). Problem is, we need to return a TDC from the static create() of TFC and TSDC, and a TotalHitsCollector shouldn't have topDocs() ...

So... IndexSearcher.search (the one that sorts by score) throws an EXC if numHits is 0...

Maybe... we should do the same for the sort-by-field case?

And, also make this new Collector that only counts hits? The exception message can then point users to this new Collector?

I'm all for not making the app handle corner cases... but, then, I don't like that you silently get bad performance. It's better to steer the apps to use the right Collector for the job?

So... IndexSearcher.search (the one that sorts by score) throws an EXC if numHits is 0... Maybe... we should do the same for the sort-by-field case?

I think IndexSearcher should not only throw the exception, in my opinion the create() method in TSDC and TFDC should also check this and throw the exception? A lot of people, also solr are instantiating the collectors themselves (although not recommeneded, because they dont know the correct booleans passed in).

+1 for TSDC and TFDC throw exception if hitcount <1

And, also make this new Collector that only counts hits? The exception message can then point users to this new Collector?

+1 to the new collector that simply counts. I have such a collector also sometimes in my code. Misusing TFDC or TSDC is wrong and uses too much resources.

"A Collector, that counts" - priceless.
And, yes, I have one of these too.

Patch.

I moved the numHits > 0 check down into TFC.create an TSDC.create, out of IndexSearcher.

And I added a new TotalHitCountCollector.

Bulk close for 3.1