Thanks Mike. That solved a query which was itching my mind for a long time.
On Thu, Apr 22, 2010 at 4:41 PM, Michael McCandless < [email protected]> wrote: > It's the IndexReader that's costly to open/warm, so ideally it should > be opened once and shared. > > The Searchers do very little on construction so re-creating per query > should be OK. > > Mike > > On Thu, Apr 22, 2010 at 6:38 AM, Samarendra Pratap <[email protected]> > wrote: > > Greetings to all. > > I have read at so many places that we should not open a Searcher for > each > > request for the sake of performance, but I have always been wondering > > whether it is actually Searcher or Reader? > > > > I have a group of index amounting to 23G which actually contains of > > different index directories. The structure is something like following > > > > Main directory > > | > > |_________ country1 > > | |___ country1-time1 (actual index) > > | |___ country1-time2 (actual index) > > | |___ country1-time3 (actual index) > > | > > |_________ country2 > > |___ country2-time1 (actual index) > > |___ country2-time2 (actual index) > > |___ country2-time3 (actual index) > > > > When application starts I open IndexReaders on all of actual index > > directories (country1-time1, country1-tim2, .... country2-time3) and keep > > them in a pool. > > > > At the time of search, IndexSearchers are created by selecting the > > appropriate IndexReaders from the pool. These IndexSearchers in turn are > > used to create a ParallelMultiSearcher. Constructors of IndexSearcher and > > ParallelMultiSearcher are run for every request. > > > > Now I believe that creating a pool of ParallelMultiSearcher itself is a > > good idea but* I wanted to know if reopening **IndexSearchers** will > really > > degrade performance irrespective of **IndexReaders** being opened once*. > > > > In my performance tests (which may not be very comprehensive) I didn't > find > > any noticeable difference. > > > > Please throw some light. > > > > > > -- > > Regards, > > Samar > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Samar
