Re: performance impact using string or float when querying ranges

2012-04-13 Thread Erick Erickson
Well, I guess my first question is whether using stirngs
is "fast enough", in which case there's little reason to
make your life more complex.

But yes, range queries will be significantly faster with
any of the Trie types than with strings. Trie types are
all numeric types.


Best
Erick

On Fri, Apr 13, 2012 at 3:49 AM, crive  wrote:
> Hi All,
> is there a big difference in terms of performances when querying a range
> like [50.0 TO *] on a string field compared to a float field?
>
> At the moment I am using a dynamic field of type string to map some values
> coming from our database and their type can vary depending on the context
> (float/integer/string); it easier to use a dynamic field other than having
> to create a bespoke field for each type of value.
>
> Marco


Re: performance impact using string or float when querying ranges

2012-04-13 Thread Yonik Seeley
On Fri, Apr 13, 2012 at 8:11 AM, Erick Erickson  wrote:
> Well, I guess my first question is whether using stirngs
> is "fast enough", in which case there's little reason to
> make your life more complex.
>
> But yes, range queries will be significantly faster with
> any of the Trie types than with strings.

To elaborate on this point a bit... range queries on strings will be
the same speed as a numeric field with precisionStep=0.
You need a precisionStep > 0 (so the number will be indexed in
multiple parts) to speed up range queries on numeric fields.  (See
"int" vs "tint" in the solr schema).

-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10




 Trie types are
> all numeric types.
>
>
> Best
> Erick
>
> On Fri, Apr 13, 2012 at 3:49 AM, crive  wrote:
>> Hi All,
>> is there a big difference in terms of performances when querying a range
>> like [50.0 TO *] on a string field compared to a float field?
>>
>> At the moment I am using a dynamic field of type string to map some values
>> coming from our database and their type can vary depending on the context
>> (float/integer/string); it easier to use a dynamic field other than having
>> to create a bespoke field for each type of value.
>>
>> Marco