lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Lucene 2.9 status (to port to Lucene.Net)
Date Tue, 28 Apr 2009 12:31:03 GMT
On Tue, Apr 28, 2009 at 8:10 AM, Uwe Schindler <> 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).


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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message