lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrien Grand (JIRA)" <>
Subject [jira] [Updated] (LUCENE-6290) Make the query -> filter migration less performance trappy
Date Tue, 24 Feb 2015 18:47:04 GMT


Adrien Grand updated LUCENE-6290:
    Attachment: LUCENE-6290.patch

Here is a patch:
 - QueryWrapperFilter rewrites to a ConstantScoreQuery with a boost of 0 in order to propagate
 - FilteredQuery rewrites to a BooleanQuery when the filter is a QueryWrapperFilter in order
to take advantage of approximations

> Make the query -> filter migration less performance trappy
> ----------------------------------------------------------
>                 Key: LUCENE-6290
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>             Fix For: Trunk, 5.1
>         Attachments: LUCENE-6290.patch
> The filter->query migration might be a bit trappy in terms of performance for our
> For instance a FilteredQuery over a TermQuery and a DocValuesRangeFilter should be migrated
to a BooleanQuery with a MUST clause for the TermQuery and a FILTER clause for the DocValuesRangeQuery.
Performance will be similar since in both case we would use the query to drive the iteration
and the filter would only be used to check documents that match the query (we would NOT try
to advance the filter iterator).
> However, if you only go half-way through the migration and end up with a FilteredQuery
over a TermQuery and a QueryWrapperFilter(DocValuesRangeQuery) then performance will be terrible
because this QueryWrapperFilter does not support random-access (which is the way such filters
were not too slow before) and hides the approximation support from the DocValuesRangeQuery.

This message was sent by Atlassian JIRA

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

View raw message