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 bot
014 6:13 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Distributed Search in Solr with different queries per shard
>
> I suppose you could, but I _really_ question whether it's a wise investment
> in time. Personally I'd treat them as two different collections and have
[mailto:erickerick...@gmail.com]
Sent: Wednesday, May 21, 2014 6:13 PM
To: solr-user@lucene.apache.org
Subject: Re: Distributed Search in Solr with different queries per shard
I suppose you could, but I _really_ question whether it's a wise investment in
time. Personally I'd treat them as two
ssage-
From: Jack Krupansky [mailto:j...@basetechnology.com]
Sent: Wednesday, May 21, 2014 6:52 PM
To: solr-user@lucene.apache.org
Subject: Re: Distributed Search in Solr with different queries per shard
Unfortunately the same query will be sent to all cores if you use the shards
parameter to
Unfortunately the same query will be sent to all cores if you use the shards
parameter to query multiple cores.
Is there some characteristic of the first core that is distinct from the
second core so that you could OR the differences between the two?
-- Jack Krupansky
-Original Message--
I suppose you could, but I _really_ question whether it's a wise
investment in time. Personally I'd treat them as two different
collections and have the app layer fire off two queries and do the
aggregation (this is a variant of "federated search" I think). This
removes your issue with having the c
