lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: MultiSegmentQueryFilter enhancement for interactive indexes?
Date Sat, 08 Jul 2006 12:14:33 GMT
Is that really necessary for a filter? It seems that a filter implies  
efficiency over a "scoring", and that filters should be able to be  
evaluated in a chained (or priority queue) fashion fairly efficiently  
without any need for 'rewrites".

With the new incremental updates of a filter (based upon a query) it  
seems that the newly proposed filtering could be far less efficient.

I think a filter change that just removes the BitSet dependency is  
all that is needed, and anything else is overkill, but I admit I am  
probably missing something here.

If these changes will eventually allow for efficient filtering based  
upon non-indexed stored fields I am all for it.

On Jul 8, 2006, at 2:24 AM, Paul Elschot wrote:

> On Saturday 08 July 2006 05:44, robert engels wrote:
>> Agreed. The interface I proposed supports both sequential and random
>> access to the filter - hiding the implementation.
>
> For query searching, random access to a Filter is only needed
> in the forward direction, e.g. by nextInclude(docNr) or skipTo(docNr).
>
> As for why it's so involved:
>
> Making a "rewritten" Filter work more like a Scorer has the advantage
> that combinations of filters can (also) be evaluated using the same
> mechanisms as currently existing for Scorers. For this, some additions
> to the existing code will be needed, like adding an
> add(Filter, BooleanClause.Occur) to BooleanQuery, and a similar
> addition of a Matcher (proposed superclass of Scorer to "rewrite" a
> Filter to) to some of the underlying scorers.
> Such occurrences of filters are only "must" and "must not", "should"
> doesn't make sense because there is no score value.
>
> Also, it makes sense to have an explain() method for a "rewritten"
> Filter, because it can be for searching a query.
>
> Regards,
> Paul Elschot
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


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


Mime
View raw message