gt; > >
> > > On Tue, Oct 1, 2013 at 4:10 PM, Desidero wrote:
> > >
> > > > Uwe,
> > > >
> > > > I was using a bounded thread pool.
> > > >
> > > > I don't know if the problem was the task overload or something
y of searching a single segment rather than iterating
> > over
> > > multiple AtomicReaderContexts, but I'd lean toward task overload. I
> will
> > do
> > > some testing tonight to find out for sure.
> > >
> > > Matt
> > >
> Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> > > -Original Message-
> > > From: Desidero [mailto:desid...@gmail.com]
> > > Sent: Tuesday, October 01, 2013
-
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Desidero [mailto:desid...@gmail.com]
> > Sent: Tuesday, October 01, 2013 11:37 PM
> > To: java-use
se a bounded thread pool.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Desidero [mailto:desid...@gmail.com]
> > Sent: Tues
PM
> To: java-user@lucene.apache.org
> Subject: Re: Query performance in Lucene 4.x
>
> For anyone who was wondering, this was actually resolved in a different
> thread today. I misread the information in the
> IndexSearcher(IndexReader,ExecutorService) constructor documentation - I
&
e.apache.org
> Subject: Re: Query performance in Lucene 4.x
>
> For anyone who was wondering, this was actually resolved in a different
> thread today. I misread the information in the
> IndexSearcher(IndexReader,ExecutorService) constructor documentation - I
> was under the impre
For anyone who was wondering, this was actually resolved in a different
thread today. I misread the information in the
IndexSearcher(IndexReader,ExecutorService) constructor documentation - I
was under the impression that it was submitting a thread for each index
shard (MultiReader wraps 20 shards,
Erick,
Thank you for responding.
I ran tests using both compressed fields and uncompressed fields, and it
was significantly slower with uncompressed fields. I looked into the lazy
field loading per your suggestion, but we don't get any values from the
returned Documents until the result set has b
Hmmm, since 4.1, fields have been stored compressed by default.
I suppose it's possible that this is a result of compressing/uncompressing.
What happens if
1> you enable lazy field loading
2> don't load any fields?
FWIW,
Erick
On Thu, Sep 26, 2013 at 10:55 AM, Desidero wrote:
> A quick update:
A quick update:
In order to confirm that none of the standard migration changes had a
negative effect on performance, I ported my Lucene 4.x version back to
Lucene 3.6.2 and kept the newer API rather than using the custom
ParallelMultiSearcher and other deprecated methods/classes.
Performance in
11 matches
Mail list logo
