- Lucene - Solr - Nutch
>
> - Original Message
> From: Geert-Jan Brits <[EMAIL PROTECTED] >
> To: solr-user@lucene.apache.org
> Sent: Monday, December 31, 2007 8:49:43 AM
> Subject: Re: big perf-difference between solr-server vs. SOlrJ
> req.process(solrserver)
>
>
Otis Gospodnetic wrote:
Maybe I'm not following your situation 100%, but it sounded like
pulling the values of purely stored fields is the slow part.
*Perhaps* using a non-Lucene data store just for the saved fields
would be faster.
For this purpose Nutch uses external files in Hadoop MapFile f
ginal Message
From: Geert-Jan Brits <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Monday, December 31, 2007 8:49:43 AM
Subject: Re: big perf-difference between solr-server vs. SOlrJ
req.process(solrserver)
Hi Otis,
I don't really see how this would minimize my number o
On Dec 31, 2007 8:58 AM, Britske <[EMAIL PROTECTED]> wrote:
> 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
> abovemen
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-process
ge indices where we successfully used BDBs for this
> purpose.
>
> Otis
>
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
> - Original Message
> From: Geert-Jan Brits <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Thur
ucene - Solr - Nutch
- Original Message
From: Geert-Jan Brits <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Thursday, December 27, 2007 11:44:13 AM
Subject: Re: big perf-difference between solr-server vs. SOlrJ
req.process(solrserver)
yeah, that makes sense.
so, in in
Brits [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 27, 2007 8:44 AM
To: solr-user@lucene.apache.org
Subject: Re: big perf-difference between solr-server vs. SOlrJ
req.process(solrserver)
yeah, that makes sense.
so, in in all, could scanning all the fields and loading the 10 fields
add up to
yeah, that makes sense.
so, in in all, could scanning all the fields and loading the 10 fields add
up to cost about the same or even more as performing the intial query? (Just
making sure)
I am wondering if the following change to the schema would help in this
case:
current setup:
It's possible t
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:
> true (I guess it was
> enabled by default)
>
> Since any query returns about 10 fields (which differ from query to query) ,
> would this mean t
after inspecting solrconfig.xml I see that I already have enabled lazy field
loading by:
true (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?
T
>From a Lucene perspective, it's certainly possible to do lazy field
loading. That is, when loading a document you can determine at
run time what fields to load, even on a per-document basis. I'm
not entirely sure how to accomplish this in Solr, but I'd give
long odds that there's a way.
I did
Yonik Seeley wrote:
>
> On Dec 27, 2007 9:45 AM, Britske <[EMAIL PROTECTED]> wrote:
>> I am using SolrJ to communicate with SOLR. My Solr-queries perform within
>> range (between 50 ms and 300 ms) by looking at the solr log as ouputted
>> on
>> my (windows) commandline.
>>
>> However I discover
On Dec 27, 2007 9:45 AM, Britske <[EMAIL PROTECTED]> wrote:
> I am using SolrJ to communicate with SOLR. My Solr-queries perform within
> range (between 50 ms and 300 ms) by looking at the solr log as ouputted on
> my (windows) commandline.
>
> However I discovered that the following command at all
14 matches
Mail list logo
