I imagine then that this "scanning-cost" is proportional to the number of stored fields, correct?
I tested this with generating a second index with 1/10th of the product-variants (and thus 1/10th) of the stored fields. However I really don't see the expected (at least by me) drop in post-processing time (which includes lazy loading the needed fields and scanning all the stored fields). Moreover, I realized that I'm using an xsl-transform in the post-processing phase. This would contribute to the high cost I'm seeing as well I think. Can this XSL-transform in general be considered small in relation to the abovementioned costs? Thanks, Geert-Jan Yonik Seeley wrote: > > On Dec 27, 2007 11:01 AM, Britske <[EMAIL PROTECTED]> wrote: >> after inspecting solrconfig.xml I see that I already have enabled lazy >> field >> loading by: >> <enableLazyFieldLoading>true</enableLazyFieldLoading> (I guess it was >> enabled by default) >> >> Since any query returns about 10 fields (which differ from query to >> query) , >> would this mean that only these 10 of about 2000-4000 fields are >> retrieved / >> loaded? > > Yes, but that's not the whole story. > Lucene stores all of the fields back-to-back with no index (there is > no random access to particular stored fields)... so all of the fields > must be at least scanned. > > -Yonik > > -- View this message in context: http://www.nabble.com/big-perf-difference-between-solr-server-vs.--SOlrJ-req.process%28solrserver%29-tp14513964p14557779.html Sent from the Solr - User mailing list archive at Nabble.com.
