Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 20 Sep 2012 22:55:09 +1100 (NCT)
From: "Simon Willnauer (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <1894955270.101926.1348142109133.JavaMail.jiratomcat@arcas>
In-Reply-To: <422381909.101673.1348135088393.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible
 with regards to how filters are applied
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459541#comment-13459541 ] 

Simon Willnauer commented on LUCENE-4410:
-----------------------------------------

bq. We (well, Robert: thanks!) are about to cut the final 4.0 release ... we shouldn't stuff features in at the last minute.
I marked this as a blocker since it really limits to a certain type of filters. I don't think this is a last minute feature really. I'd be totally happy to have only the structural refactoring in Lucene 4.0 and add the DocFirstStrategy later if that is consider a feature though.
                
> Make FilteredQuery more flexible with regards to how filters are applied
> ------------------------------------------------------------------------
>
>                 Key: LUCENE-4410
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4410
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/search
>    Affects Versions: 4.0-BETA
>            Reporter: Simon Willnauer
>             Fix For: 5.0, 4.0
>
>         Attachments: LUCENE-4410.patch
>
>
> Currently FilteredQuery uses either the "old" lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way.
> The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org