[
https://issues.apache.org/jira/browse/LUCENE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124720#comment-13124720
]
Uwe Schindler commented on LUCENE-1536:
---------------------------------------
{quote}
hack patch that computes the heuristic up front in weight init, so it scores
all segments consistently and returns the proper scoresDocsOutOfOrder for BS1.
Uwe's new test (the nestedFilterQuery) doesnt pass yet, don't know why.
{quote}
Very easy to explain: Because it's a hack! The problem is simple: The new test
explicitely checks that acceptDocs are correctly handled by the query, which is
not the case for your modifications. In createWeight you get the first segemnt
and create the filter's docidset on it, passing *liveDocs* (because you have
nothing else). You cache this first DocIdSet (to not need to execute
getDocIdSet for the first filter 2 times) and by that miss the real acceptDocs
(which are != liveDocs in this test). The firts segment therefore returns more
documents that it should.
Alltogether, the hack is of course uncommitable and the source of outr problem
only lies in the out of order setting. The fix in your patch is fine, but too
much. The scoresDocsOutOfOrder method should simply return, what the inner
weight returns, because it *may* return docs out of order. It can still retun
them in order (if a filter needs to be applied using iterator). This is not
different to behaviour before. So the fix is easy: Do the same like in
ConstantScoreQuery, where we return the setting from the inner weight.
Being consistent in selecting scorer implementations between segments is not an
issue of this special case, it's a general problem and cannot be solved by a
hack. The selection of Scorer for BooleanQuery can be different even without
FilteredQuery, as BooleanWeight might return different different scorer, too
(so the problem is BooleanScorer that does selection of its Scorer
per-segment). To fix this, BooleanWeight must do all the scorer descisions in
it's ctor, so we would need to pass also scoreInOrder and other parameters to
the Weight's ctor.
Please remove the hack, and only correctly implement scoresDocsOutOfOrder
(which is the reason for the problem, as it suddenly returns documents in a
different order). We can still get the documents with that patch in different
order if we have random access enabled together with the filter but the old
IndexSearcher used DocIdSetIterator (in-order). We should ignore those
differences in document order, if score is identical (and Mike's output shows
scores are equal). If we want to check that the results are identical, the
benchmark test must explicitely request docs-in-order on trunk vs. patch to be
consistent. But then it's no longer a benchmark.
Conclusion: In general we explained the differences between the patches and I
think, my original patch is fine except the Weight.scoresDocsOutOfOrder, which
should return the inner Weight's setting (like CSQ does) - no magic needed. Our
patch does *not* return wrong documents, just the order of equal-scoring
documents is different, which is perfectly fine.
> if a filter can support random access API, we should use it
> -----------------------------------------------------------
>
> Key: LUCENE-1536
> URL: https://issues.apache.org/jira/browse/LUCENE-1536
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
> Affects Versions: 2.4
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Fix For: 4.0
>
> Attachments: CachedFilterIndexReader.java, LUCENE-1536-rewrite.patch,
> LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch,
> LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch,
> LUCENE-1536-rewrite.patch, LUCENE-1536-rewrite.patch,
> LUCENE-1536-rewrite.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch, LUCENE-1536.patch,
> LUCENE-1536_hack.patch, changes-yonik-uwe.patch, luceneutil.patch
>
>
> I ran some performance tests, comparing applying a filter via
> random-access API instead of current trunk's iterator API.
> This was inspired by LUCENE-1476, where we realized deletions should
> really be implemented just like a filter, but then in testing found
> that switching deletions to iterator was a very sizable performance
> hit.
> Some notes on the test:
> * Index is first 2M docs of Wikipedia. Test machine is Mac OS X
> 10.5.6, quad core Intel CPU, 6 GB RAM, java 1.6.0_07-b06-153.
> * I test across multiple queries. 1-X means an OR query, eg 1-4
> means 1 OR 2 OR 3 OR 4, whereas +1-4 is an AND query, ie 1 AND 2
> AND 3 AND 4. "u s" means "united states" (phrase search).
> * I test with multiple filter densities (0, 1, 2, 5, 10, 25, 75, 90,
> 95, 98, 99, 99.99999 (filter is non-null but all bits are set),
> 100 (filter=null, control)).
> * Method high means I use random-access filter API in
> IndexSearcher's main loop. Method low means I use random-access
> filter API down in SegmentTermDocs (just like deleted docs
> today).
> * Baseline (QPS) is current trunk, where filter is applied as iterator up
> "high" (ie in IndexSearcher's search loop).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
