On Wed, 2010-04-28 at 16:57 +0200, Erick Erickson wrote:
> And you can extend this ad nauseum. For instance, you could use 6
> fields, yy, mm, dd, HH, MM, SS and have a very small number of
> unique values in each using really tiny amounts of memory to sort down
> to the second in this case.
A ref
Great explanation Erick.
Thanks. I'll try that.
On Wed, Apr 28, 2010 at 8:27 PM, Erick Erickson wrote:
> Quick reply to question (4). Not quite right, you're not gaining anything,
> you still have a yymmddHHMMSS field that will consume all the memory
> when you sort by it.
>
> Remember that the c
Quick reply to question (4). Not quite right, you're not gaining anything,
you still have a yymmddHHMMSS field that will consume all the memory
when you sort by it.
Remember that the controlling part here is the number of unique values. So
think about two fields, yymmdd and HHMMSS. Use the HHMMSS
I have got a lot of valuable information in this thread so far.
Thanks to all.
In my last mail I mentioned only two fields because others' usage was
negligible and I thought they are not important. But now after *Toke *explained
the formulae, I think sorting on those fields would also be consuming
Solr's timestamp representation (TrieDateField) is tuned for space and
speed. It has a compressed representation, and sorts with far less
space than Strings.
Also you get something called a date facet, which lets you bucketize
facet searches by time block.
On Tue, Apr 27, 2010 at 1:02 PM, Toke Es
Samarendra Pratap [samarz...@gmail.com] wrote:
> 1. Our default option is sort by score, however almost 8% of searches use
> sorting on a field (mmddHHMMSS). This field is indexed as string (not as
> NumericField or DateField).
Guessing that the timestamp is practically unique for each documen
Sorting by score down to the second will use a lot of memory. Can you
make it less granular? And I think that switching that field to a
NumericField will give you some savings - this has come up before but
I can't remember the details. I'm sure someone else will.
--
Ian.
On Tue, Apr 27, 2010
ght memory for search application
Hi Ian. Thanks for the points
Here are my answers -
1. Our default option is sort by score, however almost 8% of searches
use
sorting on a field (mmddHHMMSS). This field is indexed as string
(not as
NumericField or DateField).
2. We are opening readers at t
Hi Ian. Thanks for the points
Here are my answers -
1. Our default option is sort by score, however almost 8% of searches use
sorting on a field (mmddHHMMSS). This field is indexed as string (not as
NumericField or DateField).
2. We are opening readers at the time of starting the application
There is no simple answer. However your app does sound to be using
rather a lot of memory for what you describe as simple searches.
Are you using lucene sorting? That can use lots of memory. How are
you using/reusing searchers/readers? Having multiple ones open, or
failing to close old ones, w
Hi.
I am searching for some guidance on right memory options for my Search
Server application. How much memory a lucene based application should be
given?
Till a few days back I was running my search server on java 1.4 with memory
options "-Xmx3600m" which was running quite fine. After upgrading
11 matches
Mail list logo
