Return-Path: 
 <java-user-return-38600-apmail-lucene-java-user-archive=lucene.apache.org@lucene.apache.org>
Delivered-To: apmail-lucene-java-user-archive@www.apache.org
Received: (qmail 91246 invoked from network); 19 Feb 2009 09:48:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 19 Feb 2009 09:48:51 -0000
Received: (qmail 51913 invoked by uid 500); 19 Feb 2009 09:48:44 -0000
Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org
Received: (qmail 51878 invoked by uid 500); 19 Feb 2009 09:48:44 -0000
Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:java-user-help@lucene.apache.org>
List-Unsubscribe: <mailto:java-user-unsubscribe@lucene.apache.org>
List-Post: <mailto:java-user@lucene.apache.org>
List-Id: <java-user.lucene.apache.org>
Reply-To: java-user@lucene.apache.org
Delivered-To: mailing list java-user@lucene.apache.org
Received: (qmail 51867 invoked by uid 99); 19 Feb 2009 09:48:44 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Feb 2009 01:48:44 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [79.170.194.127] (HELO mail.roo10.com) (79.170.194.127)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Feb 2009 09:48:36 +0000
Received: from [192.168.60.45] (78-105-13-3.dsl.cnl.uk.net [78.105.13.3])
	by mail.roo10.com (Postfix) with ESMTP id E983046100D8;
	Thu, 19 Feb 2009 09:48:13 +0000 (GMT)
Subject: Re: what's the best practice for getting "next page" of hits?
From: Joel Halbert <joel@su3analytics.com>
To: java-user@lucene.apache.org
Cc: rolarenfan@earthlink.net
In-Reply-To: <003e01c99251$7253f180$710bc30a@sv.us.sonicwall.com>
References: 
	 <2461910.1235014196372.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
	 <003e01c99251$7253f180$710bc30a@sv.us.sonicwall.com>
Content-Type: text/plain
Organization: SU3 Analytics
Date: Thu, 19 Feb 2009 09:48:12 +0000
Message-Id: <1235036892.6381.2.camel@bohr>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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