Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 5607 invoked from network); 30 Apr 2003 16:08:18 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 30 Apr 2003 16:08:18 -0000 Received: (qmail 2825 invoked by uid 97); 30 Apr 2003 16:10:20 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@nagoya.betaversion.org Received: (qmail 2818 invoked from network); 30 Apr 2003 16:10:19 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 30 Apr 2003 16:10:19 -0000 Received: (qmail 5327 invoked by uid 500); 30 Apr 2003 16:08:15 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 5296 invoked from network); 30 Apr 2003 16:08:15 -0000 Received: from smtp-out1.iol.cz (194.228.2.86) by daedalus.apache.org with SMTP; 30 Apr 2003 16:08:15 -0000 Received: from fw.shark (unknown [160.218.196.211]) by smtp-out1.iol.cz (Internet on Line ESMTP server) with ESMTP id A75AC1695C8 for ; Wed, 30 Apr 2003 18:08:27 +0200 (CEST) Received: from seznam.cz (0-4.shark [192.168.0.4]) by fw.shark (8.12.5/8.12.5) with ESMTP id h3UG7xMK004928 for ; Wed, 30 Apr 2003 18:08:01 +0200 Message-ID: <3EAFF52E.9030007@seznam.cz> Date: Wed, 30 Apr 2003 18:09:18 +0200 From: Leo Galambos User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Users List Subject: Re: When is a good time to call optimize() References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N It is evergreen of this list, I guess :-). Nobody can tell you IMHO. You would execute it, when your app is in "idle" state and you have changed the index significantly. I've already implemented an algorithm that does not need any optimize(), because the index is optimized automatically (moreover it uses less file handles - it is important when your app is under DoS time to time). Unfortunately, this solution was implemented in another OSS JAVA search engine, and it does not run with Lucene architecture AFAIK. I'm sorry. -g- Rob Outar wrote: >The product we are working on allows folks to add files to the index, remove >files from the index, add/remove fields from/to documents in the index, etc. >so the index changes quite a bit. I was calling optimize after someone >added a file or removed a file but performance was poor. After how many >changes should I call optimize? I have noticed since I stopped calling >optimize I have TONS of files in my index folder... So I need to perodically >call optimize to cut down on the number of files... So I am curious what >other folks are doing. So if anyone has an opinion/solution I would like to >hear it. > >Thanks, > >Rob > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: lucene-user-help@jakarta.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org