On Fri, Jun 10, 2011 at 6:49 PM, Uwe Schindler <[email protected]> wrote: >> Really? because I see your description of the situation as mixing two totally >> different things: > > They are connected because they follow each other. > >> 1. a situation where a distributed case returns scores different than a >> single >> node case. Who cares? This should be up to the user to make the >> appropriate tradeoffs (e.g. deciding to use distributed IDF or not, or even >> different types of caching impls like andrzej hinted at, or whatever)... but >> its >> not "wrong". > > I just mentioned that for queries that rewrite to different queries on each > node (like MTQ because TermsEnums are different) will even not produce > comparable scores with a global IDF - that’s what I wanted to say. >
only 'by default'. but you can configure constant-score-filter-rewrite and they will be completely comparable if for some reason this bothers you, so where is the problem (thats your tradeoff to make, which might be incredibly stupid for some of these MTQs, but you can still do it) > About the merging; when I look at Mikes code: > Except the global IDF and the bug in MTQ, the merging code is identical to > what MultiSearcher did before. I would in trunk even recommend to undelete > FieldDocSortedHitQueue and you have everything you need to merge two TopDocs > instances. > again, where is the bug in MTQ? 'stuff being different without special intervention' in the distributed versus single node case isn't a bug, thats my point. we need to separate what is a bug (flat out wrong, like the multisearcher demorgan thing) from scores being slightly different by default. and if was really the case that the multisearcher 'flat out wrong bug' was actually created for some theoretical equal-scores-in-all-cases perfection, man what a bad tradeoff that was! --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
