With the current scorer API one could get rid of buckettable and advance all subscores only by one document each time. I am not sure whether the bucketable implementation is really much more efficient. I only see the advantage of inlining some of the scorer.next and score.score code.
Indeed, sub-scorers could be, e.g., kept in a priority queue. This is done in ConjunctionScorer, PhraseScorer, etc. However this adds a priority queue update to the inner search loop. With long queries and with common terms this overhead can be significant. With short queries and/or with rare terms the current ScoreTable-based implementation may indeed be slower, but I believe with longer queries containing common terms it is substantially faster.
This algorithm is described in:
http://lucene.sourceforge.net/papers/riao97.ps
If we had a priority-queue-based implementation then we could benchmark these. If we found that one were faster than the other for particular classes of queries then we could have a query optimizer which automatically selects the most efficient implementation...
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
