We have a very similar situation. We cache an IndexSearcher for each index and a MultiSearcher for each combination. Both IndexSearchers and MultiSearchers are created on demand (i.e. we don't prebuild every possible combination). I think caching MultiSearchers is not necessary because it is just a thin layer on top of IndexSearchers. On the other hand, there is no penalty in caching MultiSearchers because they use very little memory. However it is important that there is only one cached IndexSearcher for a given index. So this is more or less your option #1.
I have to mention that our indexes are fairly static and the indexing process is very controlled. We update all indexes once a day. When we switch to the updated indexes, we just start with a clean cache and let the garbage collector clean up the old cache. If you have indexes that are constantly updated, you may have to be a bit more careful. Hope this helps, Alexey -----Original Message----- From: Oren Shir [mailto:[EMAIL PROTECTED] Sent: Sunday, November 20, 2005 3:45 AM To: java-user@lucene.apache.org Subject: reusing MultiSearcher vs. reusing contained IndexSearchers Hi, I'm searching several indexes combinations on random. Which method is better: 1) Keep one IndexSearcher for each index, and create a new MultiSearcher for each request according to the combination needed. 2) Keep one MultiSearcher with the scope of all the indexes, and pay the toll of searching irrelevant indexes. 3) Keep each combination of MultiSearchers. Any other thoughts? The reason I need this is that the indexes differ in time range of stored data and scope of content, all of which I know before the query. Should I step out of the box and just store everything in one huge index? It will solve this problem, but probably will create a hundred more... Thanks, Oren Shir --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
