Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 72699 invoked from network); 25 Mar 2008 01:35:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Mar 2008 01:35:32 -0000 Received: (qmail 90129 invoked by uid 500); 25 Mar 2008 01:35:20 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 90060 invoked by uid 500); 25 Mar 2008 01:35:20 -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 90042 invoked by uid 99); 25 Mar 2008 01:35:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Mar 2008 18:35:20 -0700 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 [206.190.38.58] (HELO web50304.mail.re2.yahoo.com) (206.190.38.58) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 25 Mar 2008 01:34:38 +0000 Received: (qmail 60172 invoked by uid 60001); 25 Mar 2008 01:34:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=bNoZLr3xuqoC/RVrFs36bft7FHbisN63l1G7Cou5rwdyxc8mVzNUX8KUHCIBJ9j5VC/1pkaJQAaS+wTbugn1ufl4+RbyUih8KTCFaTRgfx96yDaS0vyoIfjRcu/RP7wcwINHVJz7yWuacP4ba6cysKZ+Lwx302E1hxiyOZn+YwU=; X-YMail-OSG: MGxED3cVM1kEfUnKmraVjPgGZzi_jjrwSxa46SvIIVgZr6nwRkx1q.KanMztm7ea9fmmcH2PKUJ74lUJxq4g8IQx06Ce5Z15b2PBbtxCwd3dY0P_xFfABj5GZfIj0aFKNxyHCTcE1mAAjw-- Received: from [72.231.9.236] by web50304.mail.re2.yahoo.com via HTTP; Mon, 24 Mar 2008 18:34:48 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Mon, 24 Mar 2008 18:34:48 -0700 (PDT) From: Otis Gospodnetic Subject: Re: how to control the disk size of the indices To: general@lucene.apache.org Cc: java-user@lucene.apache.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <331829.59350.qm@web50304.mail.re2.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi Yannis, I don't think there is anything of that sort in Lucene, but this shouldn't be hard to do with a process outside Lucene. Of course. optimizing an index increases its size temporarily, so your external process would have to take that into account and play it safe. You could also set mergeFactor to 1, which should keep your index in a fully optimized state if you don't do any deletions and near-optimized state if you do deletions. You should discuss this on java-user list, though, so I'm CCing that list where you can continue the discussion. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- From: Yannis Pavlidis To: general@lucene.apache.org Sent: Monday, March 24, 2008 7:33:26 PM Subject: how to control the disk size of the indices Hi all, I wanted to ask the list whether there is an easy and efficient way to manage the size (in bytes) of a lucene index stored on disk. Basically I would like to limit lucene storing only 100 GB of information. When lucene reaches that limit then I would delete the documents (using an LRU algorithm based on timestaps) but in no case the disk space occupied by Lucene should exceed 100GB. I experimented with lucene 2.3.1 and the only I could accomplish that was by calling the optimize method (after the index size exceeded the max size) on the IndexWriter. I was looking for a more performant way to "perhaps control" Lucene on when to merge the segments so as to not exceed the pre-set limit. Any ideas or suggestions would be highly appreciated. Thanks in advance, Yannis. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org