Sigh... Forest for the trees, Toke. The date time represented as an integer _is_ the order and at the same time a global external representation. No need to jump through all the hoops I made. I had my mind full of a more general solution to the memory problem with sort.
Instead of the order-array being a long[] with order and datetime, it should be just an int[] with datetime. The FieldCacheImpl does this for INT-sorts , so there's no need for extra code if you just store the datetime as an integer (something like Integer.toString(datetimeAsInt) for the field-value) and use SortField(fieldname, SortField.INT) to sort with. If you cannot store the datetime as an integer (e.g. if you don't control the indexing), you can use the FieldCacheImpl with a custom int-parser that translates your datetime representation to int. The internal representation takes 4 bytes/document. If you need to go lower than that, I'll say you have a very uncommon setup. It can be done by making custom code and storing the order-array on disk, but access-speed would suffer tremendously for searches with millions of hits. An alternative would be to reduce the granularity of the datetime and use SortField.SHORT or ShortField.BYTE. A third alternative would be to count the number of unique datetime-values and make a compressed representation, but that would make the creation of the order-array more complex. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
