lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
Date Thu, 20 Sep 2012 12:07:08 GMT

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

Robert Muir commented on LUCENE-4410:
-------------------------------------

I don't agree with blocker either. Should it block 3.6.2 as well? 4.0 is significantly more
flexible than 3.x was.

3.x only had one way to execute a filter: leapfrog.
4.x has three ways: leapfrog, bits, and auto. the default is auto.

{code}
is.search(new FilteredQuery(q,f) {
  protected boolean useRandomAccess(Bits bits, int firstFilterDoc) {
    return false; // always leapfrog: act like 3.x
  }
});
...
is.search(new FilteredQuery(q,f) {
  protected boolean useRandomAccess(Bits bits, int firstFilterDoc) {
    return true; // never leapfrog if Bits are available
  }
});
{code}

Separately (unrelated to release management) I like this idea and I think we should do it.

But as i said on the mailing list, i think we should be tackling bugs, javadocs, and tests
and approaching stability.
it makes me nervous to add more features to our filter execution right before release.

                
> 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


Mime
View raw message