Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 73982 invoked from network); 1 Oct 2009 08:57:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Oct 2009 08:57:14 -0000 Received: (qmail 1576 invoked by uid 500); 1 Oct 2009 08:57:12 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 1503 invoked by uid 500); 1 Oct 2009 08:57:12 -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 1493 invoked by uid 99); 1 Oct 2009 08:57:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 08:57:12 +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 markrmiller@gmail.com designates 74.125.92.27 as permitted sender) Received: from [74.125.92.27] (HELO qw-out-2122.google.com) (74.125.92.27) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 08:57:01 +0000 Received: by qw-out-2122.google.com with SMTP id 5so2506330qwi.53 for ; Thu, 01 Oct 2009 01:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:references; bh=xIqjtxhoH8HZ3LJgDCWpoJf3yVM8jMznyU/BxZAdc9I=; b=N+NV0IjLGYTL0xtLoX2oxSrYI4+ukD6YDQ/zKR4lQJ5pwvURRYHsbEsbhKXsbqNPRY eb6zS+ixG27eD0pwLN4rnLl5Utska1KrDxzByE9Ph/AuBs6Rln4G0RzzZoNfS3IYNSOc ZAhGQLt2JxEhpYrQaWZu6cOVgQuOX7nl6abK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date :references; b=MUWW/8aoiLPAa4EKTkqE7+SIA/DDQNm8aCtW2aNk6tDrz1TVGUdQ9/xjNeAggGlKev c4DlBgiEMED3BU6zMvwWLo3HRsNSB7aPwqXv9VsU2qGUfikrK7w+/+3qfO9BetPRV80o uL+gJPYmoE+LnYUosh5Ow/adO34K5qTeNHLzg= Received: by 10.229.111.77 with SMTP id r13mr718460qcp.85.1254387339697; Thu, 01 Oct 2009 01:55:39 -0700 (PDT) Received: from ?10.248.67.214? (mobile-166-137-133-171.mycingular.net [166.137.133.171]) by mx.google.com with ESMTPS id 8sm601586qwj.24.2009.10.01.01.55.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Oct 2009 01:55:38 -0700 (PDT) Message-Id: <1D8230C0-B327-454E-8039-531C246FE315@gmail.com> From: Mark Miller To: "java-user@lucene.apache.org" In-Reply-To: <25695093.post@talk.nabble.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Subject: Re: Lucene 2.9 and performance of readers per segment. Date: Thu, 1 Oct 2009 04:55:32 -0400 References: <25695093.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org Per segment over many segments is actually a bit faster for none sort cases and many sort cases -but an optimized index will still be fastest - the speed benifit of many segments comes when reopening - so say for realtime search - in that case you may want to sac the opt perf for a segment tail that is faster on update turnaround time. But for straight search speed - optimized is still the the way to go. - Mark http://www.lucidimagination.com (mobile) On Oct 1, 2009, at 4:47 AM, Marc Sturlese wrote: > > Hey there, > Until now when using Lucene 2.4 I was always optimizing my index using > compound file after updating it. I was doing that because if not I > could > feel a lot performance loss in search responses. > Now in Lucene 2.9 there are per segment readers and I have read > something > about it performes better and maybe there's no need to optimze > always the > index. > For FieldCache usage I know in Lucene 2.9 due to the per segment > readers the > seed at loading time as imporved a lot if the index is not > optimized. But if > it is optimized the loading time is the same. > So, is that true that with per segment reders search request perform > almost > as good as an optimized index? Can anyone point me where to get more > information about the Lucene 2.9 per segments reader? > Thanks in advance > -- > View this message in context: http://www.nabble.com/Lucene-2.9-and-performance-of-readers-per-segment.-tp25695093p25695093.html > Sent from the Lucene - Java Users mailing list archive at Nabble.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