On Wednesday 18 May 2005 23:06, Yonik Seeley wrote:
> > > > contains(docid) and exists(docid) cannot be efficiently implemented
> > > > on a VInt based compact filter, so I'd prefer to leave these out.
> > >
> > > exists() on a BitSet is much faster than next() though...
> >
> > Yes, but the point
> > > contains(docid) and exists(docid) cannot be efficiently implemented
> > > on a VInt based compact filter, so I'd prefer to leave these out.
> >
> > exists() on a BitSet is much faster than next() though...
>
> Yes, but the point is to iterate to the next document based in information
> from
On Tuesday 17 May 2005 19:35, Yonik Seeley wrote:
> > To have the actual implementation of java.util.BitSet
> > in the interface is not really nice.
>
> Totally agree.
>
> > The FilteredQuery here:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=32965
> > has two constructors, one for a Fil
> To have the actual implementation of java.util.BitSet
> in the interface is not really nice.
Totally agree.
> The FilteredQuery here:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32965
> has two constructors, one for a Filter that provides a BitSet,
> and one for SkipFilter that provides
On Wednesday 11 May 2005 04:42, Yonik Seeley wrote:
> Hey now... you're going to obsolete all my in-house code and put me
> out of a job ;-)
We all like cherry picking.
> Could you elaborate on the advantage of having say a TermQuery that
> could be either normal-scoring or constant-scoring vs tw
On Thursday 12 May 2005 17:11, Paul Elschot wrote:
> On Tuesday 10 May 2005 22:39, Doug Cutting wrote:
...
>
> > Thoughts?
>
> Yes, thanks for combining the constant score with the one by one approach :)
That should have been:
Thanks for combining the constant score with the filters.
Regards,
the boost() is the score for matches.
Since many types of queries can become constant scoring, and attribute
like this is better than a separate query class for constant scoring queries.
> 2. Add two methods to Searcher.java:
>
>public BitSet cachedBitSet(Query) { retu
o ignore the update if the term does not fall inside
the query. This check is obviously query specific.
-Original Message-
From: Yonik Seeley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 9:42 PM
To: java-dev@lucene.apache.org
Subject: Re: constant scoring queries
Hey now... you&#
Yonik Seeley wrote:
Could you elaborate on the advantage of having say a TermQuery that
could be either normal-scoring or constant-scoring vs two different
Query classes for doing this? They seem roughly equivalent.
You could code it that way too. It would require exposing TermWeight
and TermSco
> 1. Add two methods to Query.java:
>
> public boolean constantScoring();
> public void constantScoring(boolean);
>
> When constantScoring(), the boost() is the score for matches.
>
> 2. Add two methods to Searcher.java:
>
> public BitSet cachedBitSet(Query) { return null; }
> public
Hey now... you're going to obsolete all my in-house code and put me
out of a job ;-)
Could you elaborate on the advantage of having say a TermQuery that
could be either normal-scoring or constant-scoring vs two different
Query classes for doing this? They seem roughly equivalent.
> 1. Add two m
ache the query needs to be executed as is),
but the size of the LRU cache can be controlled via a property.
-Original Message-
From: Doug Cutting [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 3:40 PM
To: java-dev@lucene.apache.org
Subject: constant scoring queries
Background: In http://issues.apache.org/bugzilla/show_bug.cgi?id=34673,
Yonik Seely proposes a ConstantScoreQuery, based on a Filter. And in
http://www.mail-archive.com/lucene-dev@jakarta.apache.org/msg08007.html
I proposed a mechanism to promote the use of Filters. Through all of
this, Paul
13 matches
Mail list logo
