Even the old RangeQuery does it. Only the new class TermRangeQuery uses constant score (and the also deprecated ConstantScoreRangeQuery).
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Wednesday, August 26, 2009 11:33 AM > To: java-dev@lucene.apache.org > Subject: Re: javadoc update help > > Unfortunately, Prefix/Wildcard/FuzzyQuery, etc., still rewrite to scoring > BooleanQuery by default, for now. In 3.0 this will change to constant > score auto mode. At least, that's the plan now... however, > QueryParser will produce queries in constant score auto mode, so we > could consider changing the default for these queries in 2.9? If we > don't want to change that default, how about something like this?: > > /** Set the maximum number of clauses permitted per > * BooleanQuery. Default value is 1024. Note that queries that > * derive from MultiTermQuery, such as such as WildcardQuery, > * PrefixQuery and FuzzyQuery, may rewrite themselves to a > * BooleanQuery before searching, and may therefore also hit this > * limit. See {...@link MultiTermQuery} for details. > */ > > Mike > > On Tue, Aug 25, 2009 at 8:14 PM, Mark Miller<markrmil...@gmail.com> wrote: > > Having a writers block here: > > > > /** Set the maximum number of clauses permitted per BooleanQuery. > > * Default value is 1024. > > * <p>TermQuery clauses are generated from for example prefix queries > and > > * fuzzy queries. Each TermQuery needs some buffer space during search, > > * so this parameter indirectly controls the maximum buffer > > requirements for > > * query search. > > * <p>When this parameter becomes a bottleneck for a Query one can use > a > > * Filter. For example instead of a {...@link TermRangeQuery} one can use > a > > * {...@link TermRangeFilter}. > > * <p>Normally the buffers are allocated by the JVM. When using for > > example > > * {...@link org.apache.lucene.store.MMapDirectory} the buffering is left > to > > * the operating system. > > */ > > > > Okay, so prefix and fuzzy queries now will use a constantscore mode > > (indirectly, a filter) when it makes sense. > > So this comment is misleading. And the parameter doesn't control the max > > buffer - it possibly provides a top cutoff. But now it doesn't even > > necessarily do that, because if the Query uses constantscore mode > > (multi-term queries auto pick by default), this setting doesn't even > > influence anything. > > > > I started to rewrite below - but then it feels like I almost need to > > start from scratch. I don't think we should claim this setting controls > > the maximum buffer requirements for query search either - thats a bit > > strong ;) And the buffer talk overall (including at the bottom) is a bit > > confusing. > > > > > > /** Set the maximum number of clauses permitted per BooleanQuery. > > * Default value is 1024. > > * <p>For example, TermQuery clauses can be generated from prefix > > queries and > > * fuzzy queries. Each TermQuery needs some buffer space during search, > > * so this parameter indirectly controls the maximum buffer > > requirements for > > * query search. > > * <p>When this parameter becomes a bottleneck for a Query one can use > a > > * Filter. For example instead of a {...@link TermRangeQuery} one can use > a > > * {...@link TermRangeFilter}. > > * <p>Normally the buffers are allocated by the JVM. When using for > > example > > * {...@link org.apache.lucene.store.MMapDirectory} the buffering is left > to > > * the operating system. > > */ > > > > I'm tempted to make it: > > > > /** Set the maximum number of clauses permitted per BooleanQuery. > > * Default value is 1024. > > */ > > > > :) > > > > Anyone have any suggestions though? > > > > -- > > - Mark > > > > http://www.lucidimagination.com > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
