FWIW, I had implemented a sort-by-payload feature which performs quite well. It has a very small memory footprint (actually close to 0), and reads values from a payload. Payloads, at least from my experience, perform better than stored fields.
On a comparison I've once made, the sort-by-payload feature performed better than the FieldCache solution, for the first search. The reason is that FieldCache reads the values from the stored fields, which is slower than payload. However subsequent sorts performed better using the FieldCache. For very large indices though, FieldCache is not an option. If it's interesting enough, I can do some work to contribute it to Lucene. It's not a very big package, but not a small one either. I also think that if this feature will go into Lucene, we can improve FieldCache to read values from the payload rather than stored fields. Shai On Tue, Jul 21, 2009 at 8:17 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : Right now, you can't really do anything about it. In the future, with the > : new FieldCache API that may go in, you could plug in a custom > implementation > : that makes tradeoffs for a sparse array of some kind. The docid is > currently > : the index into the array, but with a custom impl you may be able to use a > : sparse array object. > : Thats a ways off though. > > I have no idea if this patch still applies... > > https://issues.apache.org/jira/browse/LUCENE-769 > > ...but this thread jogged my memory of it. the lsat time i looked at it > it still needed some documentation improvements, but it seemed to have > some potential value for people who have too much data and too little RAM > to build up a FieldCache for sorting, and were willing to take the > time/space tradeoff for sorting using stored fields. > > > > -Hoss > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
