: not hard, but useful information to have handy without additional : manipulations on my part.
: our pages are the results of multiple queries. so, given a max number of : records per page (or total), the rows asked of query2 is max - query1, of in the common case, counting the number of "doc"s in a "result" is just as easy as reading some attribute containing the count. It sounds like you have a more complicated case where what you really wnat is the count of how many "doc"s there are in the entire response (ie: multiple "result" sections) ... that count is admitedly a little more work but would also be completley useless to most clients if it was included in the response (just as the number of fields in each doc, or the total number of strings in the response) ... there is a lot of metadata that *could* be included in the response, but we don't bother when the client can compute that metadata just as easily as the server -- among other things, it helps keep the response size smaller. This was actually one of the orriginal guiding principles of Solr: support features that are faster/cheaper/easier/more-efficient on the central server then they would be on the clients (sorting, docset caching, faceting, etc...) -Hoss
