Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 8897 invoked from network); 22 Oct 2009 07:03:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Oct 2009 07:03:11 -0000 Received: (qmail 4074 invoked by uid 500); 22 Oct 2009 07:03:09 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 4006 invoked by uid 500); 22 Oct 2009 07:03:08 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 3996 invoked by uid 99); 22 Oct 2009 07:03:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Oct 2009 07:03:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of simon.willnauer@googlemail.com designates 209.85.220.216 as permitted sender) Received: from [209.85.220.216] (HELO mail-fx0-f216.google.com) (209.85.220.216) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Oct 2009 07:02:58 +0000 Received: by fxm12 with SMTP id 12so9013842fxm.5 for ; Thu, 22 Oct 2009 00:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=9zI3Knhy+SvL5Nmx6yhD93XqU4NtJ9NCXbG4yXJq+/M=; b=SMvB9NEYPvQYQ75g1nEAMPsBKB+H8fr03N2M0q0w0EkR8oZh+2ERCQ0WItyspVHQCM ovLzIYrg4Pmz/RZTVHJd6Jc/EC2ZfEXu1r8Tbhp4vcjUgaUeVfiF3tqnT1llJWB2lWy1 QNS1TU/hWuXjQZOiJeDyIn3S2bOcjGsUAjcx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=MxN0rJ/T0k0kSEfgtehnXRgwTDtSWOZnI6CDAt300ij/W1lhHHs5n3WI9rz3zQjBZR yzZzHtcSi9aCgMjHZXs4P9POrvNy9g3+6FVCzIGSJvu9POWJuoYKm6HU8BkoERvOlvZz cfrp5Nub1Bn7XsnZLGP83RMQijtsBJls8P//w= MIME-Version: 1.0 Received: by 10.239.183.141 with SMTP id u13mr830261hbg.10.1256194957923; Thu, 22 Oct 2009 00:02:37 -0700 (PDT) Reply-To: simon.willnauer@gmail.com In-Reply-To: <3b5f72030910212031p6afac6abr6ac3a813bbc7de30@mail.gmail.com> References: <3b5f72030910212031p6afac6abr6ac3a813bbc7de30@mail.gmail.com> Date: Thu, 22 Oct 2009 09:02:37 +0200 Message-ID: Subject: Re: 2.9 per segment searching/caching From: Simon Willnauer To: java-user@lucene.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org Bill, per segments search does not replace index optimisation neither it prevents the performance degrade if your number of segments is increasing. Depending on how your index changes it can give you a performance improvement when reopening the index and it will certainly prevent one or another GC if a segment did not change since last opened. This will improve the overall performance but the general query performance will not be improved by per seg. search. simon On Thu, Oct 22, 2009 at 5:31 AM, Bill Au wrote: > Since Lucene 2.9 has per segment searching/caching, does query performance > degrade less than before (2.9) as more segments are added to the index? > Bill > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org