il 07, 2009 11:12 AM
To: solr-user@lucene.apache.org
Subject: Re: Coming up with a model of memory usage
Why tokenize the date? It sorts just fine as a string. --wunder
On 4/7/09 8:50 AM, "Erick Erickson" wrote:
> Your observations about date sorting are probably correct. The
> i
Why tokenize the date? It sorts just fine as a string. --wunder
On 4/7/09 8:50 AM, "Erick Erickson" wrote:
> Your observations about date sorting are probably correct. The
> issue is that the sort caches in Lucene look at the unique terms.
> There are many more unique terms (nearly every one) in
Good info to have. Thanks Erick.
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Tuesday, April 07, 2009 10:51 AM
To: solr-user@lucene.apache.org
Subject: Re: Coming up with a model of memory usage
Your observations about date sorting are probably correct
Cool, great resource, thanks.
-Original Message-
From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com]
Sent: Tuesday, April 07, 2009 10:13 AM
To: solr-user@lucene.apache.org
Subject: Re: Coming up with a model of memory usage
On Tue, Apr 7, 2009 at 8:25 PM, Joe Pollard wrote:
>
Your observations about date sorting are probably correct. The
issue is that the sort caches in Lucene look at the unique terms.
There are many more unique terms (nearly every one) in
2008-08-12T12:18:26.510
then when the field is split. You can reduce memory consumption
when sorting even more by
On Tue, Apr 7, 2009 at 8:25 PM, Joe Pollard wrote:
> It doesn't seem to matter whether fields are stored or not, but I've
> found a rather striking difference in the memory requirements during
> sorting. Sorting on a string field representing datetime like
> '2008-08-12T12:18:26.510' is about twi
It doesn't seem to matter whether fields are stored or not, but I've
found a rather striking difference in the memory requirements during
sorting. Sorting on a string field representing datetime like
'2008-08-12T12:18:26.510' is about twice as memory intense as sorting
first by '2008-08-12' and th
