That's already done for you with the queryResultCache in solrconfig.xml. the "size" parameter is essentially the number of queries for which results are stored.
Two related parameters in solrconfig.xml , queryResultWindowSize and queryResultMaxDocsCached are used to control how many entries are stored for each query. These entries are quite small, just the document ID. When you ask for documents _outside_ your range (i.e. let's say you have queryResultMaxDocsCached=50 and specify &start=100) then a _new_ entry is put in the cache that will contain the IDs of the 100-150th document in the sorted result list. If you're talking about storing the sort order for use across users in some kind of global sense, the queryResultCache doesn't do that. But before trying this I'd really pin down whether sorting is the source of any problems you're having. Once _anyone_ sorts on a field, the values for that field will be in the lower-level caches and sorting should be quite fast. So make sure you test first by comparing the queries with and without sorting (and make sure you don't measure the first few sorts that fill up the caches, that's what autowarming is all about) before expending the time and effort going down this path. Best Erick On Mon, Jun 25, 2012 at 1:08 AM, Alok Bhandari <alokomprakashbhand...@gmail.com> wrote: > Thanks for the inputs. > > Eric, Yes I was referring to the String data-type. The reason I was asking > this is that for a single customer we have multiple users and each user may > apply different search criteria before sorting on the field so if we can > cache the sorted results then it may improve the user experience with > performance. > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/How-can-I-optimize-Sorting-on-multiple-text-fields-tp3990874p3991129.html > Sent from the Solr - User mailing list archive at Nabble.com.
