You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Sandeep Mestry <sa...@gmail.com> on 2012/11/28 18:43:31 UTC

Re: Does SolrCloud support distributed IDFs?

Dear All, Can anyone suggest how long it will take to get SOLR-1632 patch
into Solr 4?

Also, it'd be good if someone has used any alternate method like Ultraseek
XPA Java library to calculate the distributed ranking?

Many Thanks,
Sandeep


On 22 October 2012 13:23, Sascha SZOTT <sz...@gmx.de> wrote:

> Hi Mark,
>
>
> Mark Miller wrote:
>
>> Still waiting on that issue. I think Andrzej should just update it to
>> trunk and commit - it's option and defaults to off. Go vote :)
>>
> Sounds like the problem is already solved and the remaining work consists
> of code integration? Can somebody estimate how much work that would be?
>
> -Sascha
>

Re: Does SolrCloud support distributed IDFs?

Posted by Walter Underwood <wu...@wunderwood.org>.
Wow, an XPA user!

The distributed search merging and global IDF calculation that we used in Ultraseek XPA is described here:

http://wunderwood.org/most_casual_observer/2007/04/progressive_reranking.html

If you have per-term document frequencies and numdocs for each shard, you can calculate global IDF. It is always possible, though maybe slow, to get per-term document frequencies, because you can do a search for just that term and use the count of matches.

The Ultraseek quality was additive, like bf. A multiplicative boost (like edismax) is much more stable over a range of boost values.

wunder
Former Ultraseek Architect
Search Guy, Chegg.com

On Nov 28, 2012, at 9:43 AM, Sandeep Mestry wrote:

> Dear All, Can anyone suggest how long it will take to get SOLR-1632 patch
> into Solr 4?
> 
> Also, it'd be good if someone has used any alternate method like Ultraseek
> XPA Java library to calculate the distributed ranking?
> 
> Many Thanks,
> Sandeep
> 
> 
> On 22 October 2012 13:23, Sascha SZOTT <sz...@gmx.de> wrote:
> 
>> Hi Mark,
>> 
>> 
>> Mark Miller wrote:
>> 
>>> Still waiting on that issue. I think Andrzej should just update it to
>>> trunk and commit - it's option and defaults to off. Go vote :)
>>> 
>> Sounds like the problem is already solved and the remaining work consists
>> of code integration? Can somebody estimate how much work that would be?
>> 
>> -Sascha
>> 

--
Walter Underwood
wunder@wunderwood.org