Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <D05FEBD94AB544A98BFCEC40D5864167@VEGA>
References: <85d3c3b60904161412t2cb9d63ekedd6d36a83f7eb12@mail.gmail.com>
	 <FF9845F2B6E540DCA691F968ED9674B9@aroushlt>
	 <9ac0c6aa0904241249nb8ab78fu842bd1bcc0d149ec@mail.gmail.com>
	 <C611362BA2C245DEB9B00C20BCF5940B@VEGA>
	 <A7A2A6BA476C4FBAA827E53630877FBF@VEGA>
	 <9ac0c6aa0904261055g4fe81eecyf63daa1deeb9d19a@mail.gmail.com>
	 <D05FEBD94AB544A98BFCEC40D5864167@VEGA>
Date: Tue, 28 Apr 2009 08:31:03 -0400
Message-ID: <9ac0c6aa0904280531t4d982069tcf0fbe8359e81192@mail.gmail.com>
Subject: Re: Lucene 2.9 status (to port to Lucene.Net)
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Tue, Apr 28, 2009 at 8:10 AM, Uwe Schindler <uwe@thetaphi.de> wrote:

>> It's awesome that you no longer have to warm your searchers... but be
>> careful when a large segment merge commits.
>
> I know this, but in our case (e.g. creating a IN-SQL list, collecting
> measurement parameters from the documents) the warming is not really needed,
> it would only be a problem if it is very often (the index is updated every
> 20 minutes) and it must reload the whole field cache (takes 3-5 seconds on
> our machine). So a large merge taking 1-2 seconds for cache reloading is no
> problem (the users have the same problem with sorted results). If our index
> gets bigger, I will add warming in my search/cache implementation after
> reopening, for that it would be nice, to have the list of reopened segments
> (I think there was a issue about it, or is there an implementation?).
> In our case, most time takes the query in the SQL data warehouse after it,
> so 1 second additionally for building the SQL query is not much.

OK that's great.

>> Did you hit any snags/problems/etc. that we should fix before releasing
>> 2.9?
>
> Until now, I have not seen any further problems. What I have seen befor is
> already implemented in Lucene with our active issue communication and all
> these issues :-)

Tell me about it... hard to keep them all straight!  Lot's of great
improvements in 2.9...

> I still wait for the step towards moving trie (and also the new automaton
> regex query) to core and the modularization (hopefully before 2.9, to not
> create new APIs that change/deprecate later).

+1

We need to do something about modularization / move trie to core before 2.9.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org