lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6458) MultiTermQuery's FILTER rewrite method should support skipping whenever possible
Date Wed, 29 Apr 2015 14:11:08 GMT


David Smiley commented on LUCENE-6458:

bq. Maybe we could change TermsQuery.rewrite to rewrite to a boolean query (wrapped in a CSQ)
when there are few terms? This would avoid having to worry about this in every query parser.

You read my mind ;-)  I had that thought right after I posted.

bq. In my opinion, the issue with rewriting to a BooleanQuery is that its scorer needs to
rebalance the priority queue whenever it advances, which is O(log(#clauses)). So it gets slower
as you add new optional clauses while the way TermsQuery works doesn't care much about the
number of matching terms. I don't think the total number of index terms is relevant?

Ah; I haven't looked in a while so I didn't know about the priority-queue over there in BooleanQuery
(DisjunctionScorer actually).  Never mind.

> MultiTermQuery's FILTER rewrite method should support skipping whenever possible
> --------------------------------------------------------------------------------
>                 Key: LUCENE-6458
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>         Attachments: LUCENE-6458.patch
> Today MultiTermQuery's FILTER rewrite always builds a bit set fom all matching terms.
This means that we need to consume the entire postings lists of all matching terms. Instead
we should try to execute like regular disjunctions when there are few terms.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message