The data in stored fields that is fetched back is in different files than the index data. So, when you ask for documents you are asking for more disk i/o. The different fields are in different places on the disk, so if you request only 1 out of 20 fields, the query will be slightly faster. I once measured a 5% improvement in "1 field v.s. all fields" but it's different for each index.
On Tue, Jan 19, 2010 at 3:44 AM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Jan 18, 2010, at 11:17 AM, Yonik Seeley wrote: > >> On Mon, Jan 18, 2010 at 8:57 AM, Erick Erickson <erickerick...@gmail.com> >> 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. >> >> There's also the priority queue used to collect the top matches that >> needs to remain ordered. >> Finding and scoring matching documents will normally dominate the >> time, but if "N" becomes large (for collecting the top N matches), the >> priority queue operations can become significant. > > > See also https://issues.apache.org/jira/browse/SOLR-1726 > > -------------------------- > Grant Ingersoll > http://www.lucidimagination.com/ > > Search the Lucene ecosystem using Solr/Lucene: > http://www.lucidimagination.com/search > > -- Lance Norskog goks...@gmail.com
