: schema.) My evidence for this is the documentCache stats reported by : solr/admin. If I request "rows=10&fl=id" followed by : "rows=10&fl=id,title" I would expect to see the 2nd request result in : a 2nd insert to the cache, but instead I see that the 2nd request hits : the cache from the 1st request. "rows=10&fl=*" does the same thing.
your evidence is correct, but your interpretation is incorrect. the objects in the documentCache are lucene Documents, which contain a List of Field refrences. when enableLazyFieldLoading=true is set, and there is a documentCache Document fetched from the IndexReader only contains the Fields specified in the fl, and all other Fields are marked as "LOAD_LAZY". When there is a cache hit on that uniqueKey at a later date, the Fields allready loaded are used directly if requested, but the Fields marked LOAD_LAZY are (you guessed it) lazy loaded from the IndexReader and then the Document updates the refrence to the newly actualized fields (which are no longer marked LOAD_LAZY) So with different "fl" params, the same Document Object is continually used, but the Fields in that Document grow as the fields requested (using the "fl" param) change. : will *not* result in an insert to queryResultCache. I have tried : various increments--10, 100, 200, 500--and it seems the magic number : is somewhere between 200 (cache insert) and 500 (no insert). Can : someone explain this? In addition to the <queryResultMaxDocsCached> config option already mentioned (which controls wether a DocList is cached based on it's size) there is also the <queryResultWindowSize> config option which may confuse your cache observations. if the window size is "50" and you ask for start=0&rows=10 what actually gets cached is "0-50" (assuming there are more then 50 results) so a subsequent request for start=10&rows=10 will be a cache hit. -Hoss
