"Search the entire corpus" makes it sound like Solr is grepping the documents. The corpus has already been converted to an inverted index before the search, so only the terms in the query are retrieved.
For basic, relevance-sorted search, there are two kinds of work done by Solr: work per query term and work per document. The work per query term depends on the number of query terms. The work per document depends on the number of documents (rows) requested and the number of fields requested. Search times are not "unchanged" when you request more documents. If you request 10K documents, your search will be much, much slower than if you request 10. wunder On Jan 18, 2010, at 5:57 AM, Erick Erickson wrote: > Nope. The problem is that SOLR needs to create a ranked > list. It has to search the entire corpus every time. There's > always the possibility that the very last document examined > would rank highest. > > So the search times should be unchanged, no matter how > many rows you return, but the time to assemble and transmit > the return packet will vary. > > HTH > Erick > > On Mon, Jan 18, 2010 at 12:05 AM, Gora Mohanty <g...@srijan.in> wrote: > >> Hi, >> >> Does specifying a smaller number of rows, e.g., with >> q=test&start=0&rows=XX affect the query efficiency? >> I realise, of course, that increasing the number of >> rows will lead to inefficiencies in data transfer. >> This is with a standard Solr setup, without sharding, >> etc. >> >> Seems like a newbie query, but I cannot seem to find >> documentation on it, nor did my experiments with measuring >> search times show any definitive results. >> >> Regard, >> Gora >>
