On Fri, Oct 29, 2010 at 4:21 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : > Why don't we just include the start & rows (modulo the window size) in > : > the cache key? > : > : The implementation of equals() would be rather difficult... actually > : impossible w/o abusing the semantics. > : It would also be impossible w/o the Map implementation guaranteeing > : what object was on the LHS vs the RHS when equals was called. > : > : Unless I'm missing something obvious? > > You've totally confused me. > > What i'm saying is that SolrIndexSearcher should consult the window size > before consulting the cache -- the start param should be rounded down to > the nearest multiple of hte window size, and start+rows (ie: end) should > be rounded up to one less then the nearest multiple of the windows size, > and then that should be looked up in the cache.
That's already done. In "example", do q=*:*&rows=12 q=*:*&rows=16 and you should see a queryResultCache hit since queryResultWindowSize is 20 and both requests round up to that. *but* if you do this (with an index with more than 20 docs in it) q=*:*&rows=25 Currently that query will round up to 40, but since nResults (start+row) isn't in the key, it will still get a cache hit but then not be usable. Now, if your proposal is to put nResults into the key, we then have a worse problem. Assume we're starting over with a clean cache. q=*:*&rows=25 // cached under a key including nResults=40 q=*:*&rows=15 // looked up under a key including nResults=20... not found! > but that's why people are suppose to pick a window size greater > then the largest number of rows typically requested) Hmmm, I don't think so. If that were the case, there would be no need for two parameters (no need for queryResultWindowSize) since we would always just pick queryResultMaxDocsCached. -Yonik http://www.lucidimagination.com
