[
https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459556#comment-13459556
]
Uwe Schindler edited comment on LUCENE-4410 at 9/20/12 11:34 PM:
-----------------------------------------------------------------
Hi,
I am also against rushing this in with 4.0. There is no slowdown in comparison
to Lucene 3.6. My problems are also in the patch:
- I hate the crazy not-really-random access Bits impl in the DocFirstStrategy!
It is definitely not random access, so it violates the contract. In this case
the standard LeapFrog approach should be used (if not random access DocIdSet).
- I dont really see an improvement. The Bits interface is not allowed to throw
IOException, so the filter should *only* return a Bits interface if its a very
fast random access implementation. In all other cases the filter must not
suport Bits and then LeapFrog has to be used.
- I would only see an improvement if the method Filter.getDocIdSet() is only
called after the scorer hit the first document - but this does not work with
random access. This was also not done in 3.6, so we should not rush.
- The ctor strategy param should never be NULL. The ctor without strategy
should pass the explicit one down to this(..., Strategy)
was (Author: thetaphi):
Hi,
I am also against rushing this in with 4.0. There is no slowdown in comparison
to Lucene 3.6. My problems are also in the patch:
- I hate the crazy not-really-random access Bits impl in the DocFirstStrategy!
It is definitely not random access, so it violates the contract. In this case
the standard LeapFrog approach should be used (if not random access DocIdSet).
- I dont really see an improvement. The Bits interface is not allowed to throw
IOException, so the filter should *only* return a Bits interface if its a very
fast random access implementation. In all other cases the filter must not
suport Bits and then LeapFrog has to be used.
- I would only see an improvement if the method Filter.getDocIdSet() is only
called after the scorer hit the first document - but this does not work with
random access. This was also not done in 3.6, so we should not rush.
> 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: [email protected]
For additional commands, e-mail: [email protected]
