The manual suggested by Otis would happen inside of Solr. We use the last-component to do the sub-query and then merge the results. Since it's a new sub-query the relevancy and sorting should be independent of the main query.
Thanks, Kalyan Manepalli -----Original Message----- From: Nicolas Pastorino [mailto:n...@ez.no] Sent: Thursday, May 07, 2009 10:21 AM To: solr-user@lucene.apache.org Subject: Re: large index vs multicore Hi, and sorry for slightly hijacking the thread, On Mar 26, 2009, at 2:54 , Otis Gospodnetic wrote: > > Hi, > > Without knowing the details, I'd say keep it in the same index if > the additional information shares some/enough fields with the main > product data and separately if it's sufficiently distinct (this > also means 2 queries and manual merging/joining). Where would this manual merging/joining occur? At the client-side or inside Solr, before returning the results ? I was wondering what relevancy, sorting, etc. would become. -- Nicolas > > Otis -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > ----- Original Message ---- >> From: "Manepalli, Kalyan" <kalyan.manepa...@orbitz.com> >> To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> >> Sent: Wednesday, March 25, 2009 5:46:40 PM >> Subject: large index vs multicore >> >> Hi All, >> In my project, I have one primary core containing all >> the basic >> information for a product. >> Now I need to add additional information which will be searched >> and displayed in >> conjunction with the product results. >> My question is - From design and query speed point of - should I >> add new core to >> handle the additional data or should I add the data to the >> existing core. >> >> The data size is not very large around 150,000 - 200,000 documents. >> >> Any insights into this will be helpful >> >> Thanks, >> Kalyan Manepalli > -- Nicolas Pastorino Consultant - Trainer - System Developer Phone : +33 (0)4.78.37.01.34 eZ Systems ( Western Europe ) | http://ez.no
