[ 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.