Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 87690 invoked from network); 7 Oct 2007 11:48:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Oct 2007 11:48:26 -0000 Received: (qmail 39316 invoked by uid 500); 7 Oct 2007 11:48:07 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 39262 invoked by uid 500); 7 Oct 2007 11:48:07 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 39251 invoked by uid 99); 7 Oct 2007 11:48:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Oct 2007 04:48:07 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Oct 2007 11:48:10 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D95E271422B for ; Sun, 7 Oct 2007 04:47:50 -0700 (PDT) Message-ID: <24534182.1191757670885.JavaMail.jira@brutus> Date: Sun, 7 Oct 2007 04:47:50 -0700 (PDT) From: "Michael McCandless (JIRA)" To: java-dev@lucene.apache.org Subject: [jira] Resolved: (LUCENE-1023) When the index has more than 1 segment, norms take 2 bytes of RAM per norm not 1 In-Reply-To: <4402549.1191677630710.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1023. ---------------------------------------- Resolution: Invalid Woops ... I was mistaken here. MultiSegmentReader calls this method on each SegmentReader: norms(String field, byte[] result, int offset) and that method does not populate the cache inside SegmentReader (though it will use it if it's already populated). MultiReader does the same thing too. So this is not an issue. > When the index has more than 1 segment, norms take 2 bytes of RAM per norm not 1 > -------------------------------------------------------------------------------- > > Key: LUCENE-1023 > URL: https://issues.apache.org/jira/browse/LUCENE-1023 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1, 2.2, 2.3 > Reporter: Michael McCandless > Assignee: Michael McCandless > Priority: Minor > > When norms are loaded for an index with multiple segments, > MultiSegmentReader caches a byte array for all norms (concatenated > from all segments), and SegmentReader also caches a byte array for its > norms. I think MultiSegmentReader should somehow tell SegmentReader > not cache its own norms. For a large index this will save quite a bit > of memory (1 byte per document per field-with-norms). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org