1> Don't use sint, it's being deprecated. And it'll take up more space
than a TrieDate
2> Precision. Sure, use the coarsest time you can, normalizing
everything to day would be a good thing.
You won't get any space savings by storing to day resolution, it's
just a long under the covers. But
depend
Ranges on String are painfully slow.
Format them as MMDD and store as class="solr.TrieIntField"
precisionStep="8" omitNorms="true" positionIncrementGap="0"
On Thu, Feb 23, 2012 at 10:19, findbestopensource
wrote:
> Yes. By storing as String, You should be able to do range search. I am not
>
Yes. By storing as String, You should be able to do range search. I am not
sure, which is better, storing as String / Integer.
Regards
Aditya
www.findbestopensource.com
On Thu, Feb 23, 2012 at 1:25 PM, Jason Toy wrote:
> Can I still do range searches on a string? It seems like it would be m
Can I still do range searches on a string? It seems like it would be more
efficient to store as an integer.
> Hi,
>
> You could consider storing date field as String in "MMDD" format. This
> will save space and it will perform better.
>
> Regards
> Aditya
> www.findbestopensource.com
>
>
>
Hi,
You could consider storing date field as String in "MMDD" format. This
will save space and it will perform better.
Regards
Aditya
www.findbestopensource.com
On Thu, Feb 23, 2012 at 11:55 AM, Jason Toy wrote:
> I have a solr instance with about 400m docs. For text searches it is
> per
I have a solr instance with about 400m docs. For text searches it is perfectly
fine. When I do searches that calculate the amount of times a word appeared in
the doc set for every day of a month, it usually causes solr to crash with out
of memory errors.
I calculate this by running ~30 queri
