PROTECTED]>
wrote:
> On Mon, Apr 14, 2008, Chris Hostetter wrote about "Re: Sorting consumes
> hundreds of MBytes RAM":
> > : And question #2: what am I going to do against it? Index sharding?
> >
> > The only suggestion i can offer is to take a look at LUCENE-
On Mon, Apr 14, 2008, Chris Hostetter wrote about "Re: Sorting consumes
hundreds of MBytes RAM":
> : And question #2: what am I going to do against it? Index sharding?
>
> The only suggestion i can offer is to take a look at LUCENE-769 ... it
> takes a completley differn
Timo - correct and correct.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Timo Nentwig <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Tuesday, April 15, 2008 3:22:15 AM
Subject: Re: Sorting consumes hundreds of MBytes RAM
W
odnetic <[EMAIL PROTECTED]>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org
Subject: Re: Sorting consumes hundreds of MBytes RAM
Timo,
That is true. The only think I can recommend at the moment is to make sure you
specify the correct data type. If your sort field is a nume
: How does this work internally? It seems as if all data for this field found
in
: the entire index is read into memory (?).
You can think of it as an "inverted-inverted index" Lucene needs a data
structure it can usefor fast lookups where the key is the docId and the
value is something "com
<[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Sunday, April 13, 2008 4:45:37 PM
Subject: Sorting consumes hundreds of MBytes RAM
Hi!
I found that when sorting the search result -depending on the amount of data
in the field to sort by - this can easily lead to FieldCacheImpl to al
Hi!
I found that when sorting the search result -depending on the amount of data
in the field to sort by - this can easily lead to FieldCacheImpl to allocate
hundreds of MByte RAM.
How does this work internally? It seems as if all data for this field found in
the entire index is read into memo