lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Halbert <j...@su3analytics.com>
Subject Re: what's the best practice for getting "next page" of hits?
Date Thu, 19 Feb 2009 09:48:12 GMT
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 <emailgane@yahoo.co.in>
Reply-To: java-user@lucene.apache.org
To: java-user@lucene.apache.org, rolarenfan@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: <rolarenfan@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
> 

Send instant messages to your online friends http://in.messenger.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message