Yonik Seeley wrote: > > No, they will be roughly the same speed. > What you *could* try to do is always *index* documents in postid/date > order... then sorting would not require any FieldCache entry. It > would require a minor change to Solr (allow sorting on lucene internal > docid, which matches the order that documents are added to an index). > OK, I will look into that, if would be nice to avoid the delay when building fieldcaches after a commit.
Yonik Seeley wrote: > > If you need range queries, SortableIntField values are ordered > correctly for them to work. > For sorting, both int and sint fields work... the difference is in how > the FieldCache entry is built. > For IntField, an Integer.parseInt(str) needs to be done for each > distinct str. > SortableIntField is sorted like strings... the ordinal (order in the > index) is recorded for each distinct value. > > So sint will build the FieldCache faster, but the string values will > cause the entry to be larger. Aftert the FieldCache entry is built, > both int and sint should be comparable in speed. > I will test it and see what works the best, I think we would prefer being able to build the fieldcaches faster. Thanks for all the helpful explanations/hints :) -- View this message in context: http://www.nabble.com/Optimizing-a-schema-tf2071403.html#a5708887 Sent from the Solr - User forum at Nabble.com.
