Replying to a post on solr-user ... : From: Lance Norskog : Subject: RE: Sorting performance
: Since 'sint' is needed to do range queries on a field, and 'int' is needed : for efficient sorting, we wound up have one field of each type and a : <copyField> to make sure they both get the same numbers. Yes, it's : annoying. it never relaly occured to be before, until this post, when i went to double check the code in SortableIntField and SortableFloatField, but why do they use SortField.STRING instead of a SortComparator that passes a custom IntParser or FloatParser to FieldCache.getInts() and FieldCache.getFloats()? I actually that it was working this way until i noticed this comment ... is the assumption that it's better to just use the StringIndex because it's faster to build even though it takes more memory? At the very least it seems like it could be a worthwhile option to expose for these fieldtypes ... use less ram to sort but having warming queries take longer. (Wouldn't switching to the int and float FieldCaches also make ValueSource queries faster since the parsing only would be done once?) -Hoss
