Don't create a LeafCollector when the Scorer for the leaf is null #562
Conversation
| // there is no doc of interest in this reader context | ||
| // continue with the following leaf | ||
| continue; | ||
| } | ||
| BulkScorer scorer = weight.bulkScorer(ctx); |
There was a problem hiding this comment.
Should we also update javadocs for Collector.getLeafCollector that it will (may?) not be called when query can determine there will be no hits in this segment?
|
I had considered something like that in the past but didn't like the fact that it made things slower with queries whose bulk scorer is costly to create (eg. range or multi-term) and collectors that can skip entire segments by raising a |
|
Oh good point! I hadn't realized that creating a scorer could be the more
expensive path. Actually I mostly just saw this as a cleanup with only
slighlt positive or negligble speed gain. Our Collectors are not that
expensive to create, so I think this is not really needed and we should not
do it
…On Tue, Feb 5, 2019 at 4:32 PM Adrien Grand ***@***.***> wrote:
I had considered something like that in the past but didn't like the fact
that it made things slower with queries whose bulk scorer is costly to
create (eg. range or multi-term) and collectors that can skip entire
segments by raising a CollectionTerminatedException in getLeafCollector.
Maybe we could have a way to construct bulk scorers in two steps similarly
to Weight#scorerSupplier for regular scorers so that we could check
whether a bulk scorer might have any hits without paying the full
construction price. I expect this would only help if a leaf collector is
expensive to construct, with which collector are you seeing slowdowns
because Lucene is constructing leaf collectors on segments that don't have
matches?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#562 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA56QaNX_JxrSCBz9NVnJXdUIqU5aUmIks5vKfiEgaJpZM4ahKzm>
.
|
| import static junit.framework.Assert.assertTrue; | ||
| import static org.junit.Assert.assertEquals; | ||
| import static org.junit.Assert.assertFalse; | ||
| import static org.junit.Assert.assertTrue; |
There was a problem hiding this comment.
Does this change need to be part of this CR?
There was a problem hiding this comment.
It's not required. I did it because junit.framework.Assert is deprecated.
No description provided.