[
https://issues.apache.org/jira/browse/SOLR-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829868#action_12829868
]
Lance Norskog commented on SOLR-1754:
-------------------------------------
I thought that this is how sorting works:
An array of java ints, 4 bytes apiece, is allocated with one for every document
in the index. The ints are set to each successive docid.
A separate array of objects is allocated, one entry for every term in the
field. This array is sorted by the term value. There is other data hanging off
this that we will not discuss.
My understanding was that if the field type is a Java int, the second array is
not created, and only the first is needed. And that the Solr IntField creates
this type, and so if the field is a Solr IntField sorting requires less memory
because it does not make the second array.
If the field is some other type, like a TrieField, sorting on that field cannot
possibly use the same amount of memory as sorting on a Java int field. Clearly
something about this is wrong. Please set me straight.
> Legacy numeric types do not check input for bad syntax
> ------------------------------------------------------
>
> Key: SOLR-1754
> URL: https://issues.apache.org/jira/browse/SOLR-1754
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Lance Norskog
> Fix For: 1.5
>
>
> The legacy numeric types do not check their input values for valid input. A
> text string is accepted as input for any of these types: IntField, LongField,
> FloatField, DoubleField. DateField checks its input.
> In general this is a no-fix, except: that IntField is a necessary memory type
> because it cuts memory use in sorting.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
