I agree with Eric that this is premature unless you can show that it makes a difference.
Firstly why are you splitting the data into multiple time tiers (one recent, and one all) and then waiting to merge results from all of them? Time tiering is useful when you can do the search separately on both and then pick the one which comes back with full results first (usually will be the recent one but it might not have as many results as you want). The way you are trying to aggregate the data is sharding, where one of the cores doesn't have the data the other one has. So you could just 'optimize' by not having the data present in the historical collection. We have support for custom sharding keys now in Solr, haven't used it personally but that might be worth a shot.. On 21 May 2014 14:57, "Avner Levy" <av...@checkpoint.com> wrote: > I have 2 cores. > One with active data and one with historical data (for documents which > were removed from the active one). > I want to run Distributed Search on both and get the unified result (as > supported by Solr Distributed Search, I'm not using Solr Cloud). > My problem is that the query for each core is different. > Is there a way to specify different query per core and still let Solr to > unify the query results? > For example: > Active data core query: select all green docs > History core query: select all green docs with year=2012 > Is there a way to extend the distributed search handler to support such a > scenario? > Thanks in advance, > Avner > ยท One option is to send a unified query to both but then each core > will work harder for no reason. > >
