Well, sorting requires that all the unique values in the target field get loaded into memory, so it's possible that's the culprit. This would likely only show up if you have a relatively small test set, or the multivalued entries that you added are new to your corpus. To test this stab in the dark, I'd start by counting the number of unique terms in the field for the multi-valued and non-multi-valued versions....
But a larger question is whether what your doing is worthwhile even as just a measurement. You say "This is good for me, I don't care for my tests". I claim that you do care. You really can't trust measurements of something when the behavior is undefined. Which the behavior of sorting on mutivalued fields is. And it's measuring something that you had better not be doing anyway in a real application, so what's the point? Best Erick On Sat, Jun 19, 2010 at 7:30 AM, Marc Sturlese <marc.sturl...@gmail.com>wrote: > > Hey Erik, > I am currently sorting by a multiValued. It apears a feature tha't you may > not know wich of the fields of the multiValued field makes the document be > in that position. This is good for me, I don't care for my tests. > What I need to know if there is any performance issue in all of this. > Thanks > -- > View this message in context: > http://lucene.472066.n3.nabble.com/performance-sorting-multivalued-field-tp905943p907502.html > Sent from the Solr - User mailing list archive at Nabble.com. >