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
-
From: Avner Levy
Sent: Wednesday, May 21, 2014 9:56 AM
To: solr-user@lucene.apache.org
Subject: Distributed Search in Solr with different queries per shard
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
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
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
Hi all,
I am seeing some inconsistent behavior with facets, specifically range facets,
on Solr 4.3. Running the same query several times (pressing F5 on the browser)
produces different facet ranges when doing distributed searches, as some times
it doesn't include some of the "buckets". The resu
Hi Grant,
What i have got from your comments is:
1. We will have to add a support for BoostingTermQuery which
extends SpanTermQuery like in lucene payload support. In current world we
anyway have other class which is extending SpanTermQuery . Where should i
put this class or newly built BoostingTe
On Jul 9, 2009, at 11:58 PM, Sumit Aggarwal wrote:
Hi,
1. Calls made to multiple shards are made in some concurrent fashion
or
serially?
Concurrent
2. Any idea of algorithm followed for merging data? I mean how
efficient it
is?
Not sure, but given that Yonik implemented it, I suspect
Hi,
1. Calls made to multiple shards are made in some concurrent fashion or
serially?
2. Any idea of algorithm followed for merging data? I mean how efficient it
is?
3. Lucene provides payload concept. How can we make search using that in
solr. My application store payloads and use search using our
11 matches
Mail list logo
