my private investigation already left me sceptic about the outcome of this
issue,
but I've decided to post it as a final resort.
What did you do in your private investigation?
Suppose I have an index of about 5,000,000 docs
and I am running a single term queries against it, including queries which
return say 1,000,000 or even more hits.
The hits are sorted by some column and I am happy with the query execution
time (i.e. the time spent in the IndexSearcher.query(...) method).
Now comes the problem: it is a product requirement that the client is
allowed to quickly access (by scrolling) a random page of the result set.
Put in different words the app must quickly (in less that a second) respond
to requests like: "Give me the results from No 567100 to No 567200"
(remember the results are sorted thus ordered).
Sorted by descending relevance (the default), or in some other way?
If a search is fast enough, as you report, then you can simply start your access to Hits at the appropriate spot. For the current systems I'm working on, this is the approach I've used - start iterating hits at (pageNumber - 1) * numberOfItemsPerPage.
Is that approach insufficient?
Erik
I took a look at Lucene's internals which only left me with the suspision
that this is an impossible task.
Would anyone, please, prove my suspision wrong?
Regards Stanislav
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
