hmm...I guess this javadoc from MultiTermQuery confused me:
* Note that {...@link QueryParser} produces
* MultiTermQueries using {...@link
* #CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} by default.
Uwe Schindler wrote:
> 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
>
>
--
- 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
