On Tue, Apr 28, 2009 at 8:10 AM, Uwe Schindler <u...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
