Out of interest, if the index is entirely in memory (using a RAMDir) is there any significant different in performance between options (a) and (b) as outlined below?
Rgs, Joel -----Original Message----- From: Ganesh <emailg...@yahoo.co.in> Reply-To: java-user@lucene.apache.org To: java-user@lucene.apache.org, rolaren...@earthlink.net Subject: Re: what's the best practice for getting "next page" of hits? Date: Thu, 19 Feb 2009 10:48:02 +0530 Your solution (b) is better rather than using your own way of paging. Do search for every page and collect the (pageno * count) results, discard (pageno-1 * count) and display the last count results to the User. This is fast and efficient. Regards Ganesh ----- Original Message ----- From: <rolaren...@earthlink.net> To: <java-user@lucene.apache.org> Sent: Thursday, February 19, 2009 8:59 AM Subject: what's the best practice for getting "next page" of hits? > R2.4 > > So, I may well be missing something here, but: I use > > <pseudoCode>IndexSearcher.search(someQuery, null, count, new > Sort());</pseudoCode> > > to get an instance of TopFieldDocs (the "Hits" is deprecated). So far, all > fine; I get a bunch of documents. Now, what is the Lucene-best-practice > for getting the *next* batch of size "count"? (Didn't see this discussed > anywhere, but maybe I missed it.) > > a) I could guess that my users will never want more than "N*count", for > some value of N, request that right up front, and do all my own "paging" > using the one TopFieldDocs instance; > > b) I could assume that (a) will be an inefficient memory and time hog, and > when the user clicks "Next" (or whatever), then ... (with i starting at > "1") get a new TopFieldDocs with "(++i)*count", and out of that discard > the first "i*count" items? In the limit (as i => N) that uses up just as > much space and memory, but does so lazily (better); > > c) some compromise of (a) and (b), where I get M*count, do my own paging, > and when the user asks for the (i+1)==(M+1)-th batch, then get another > M*count (maybe faster, but also maybe bigger amortized memory footprint); > > d) something else? (I'd hope for something like a search() method with > some parameter saying, in effect, "such and such a range of hits" ...) > > thanks, > Paul > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
