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
Hello,
Over the last few weeks I've been working on upgrading an application from
Lucene 3.x to Lucene 4.x in hopes of improving performance. Unfortunately,
after going through the full migration process and playing with all sorts
of tweaks I found online and in the documentation, Lucene 4 is runn
12 matches
Mail list logo
