lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Britske <>
Subject Re: big perf-difference between solr-server vs. SOlrJ req.process(solrserver)
Date Mon, 31 Dec 2007 13:58:04 GMT

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?


Yonik Seeley wrote:
> On Dec 27, 2007 11:01 AM, Britske <> 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:
Sent from the Solr - User mailing list archive at

View raw message