[
https://issues.apache.org/jira/browse/LUCENE-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734583#action_12734583
]
Michael McCandless commented on LUCENE-1644:
--------------------------------------------
bq. I would change this to simply always throw UOE on any change in
ConstantScoreRangeQuery.
OK will do.
bq. A good thing would also be to set the mode to filter automatically, if
precisionStep >6 for longs (valSize=64) and precStep > 8 for ints (valSize=32),
because here the number of terms is often too big.
Will do.
Hmm -- my last patch hit this test failure, after I had switched to
CONSTANT_SCORE_AUTO for NumericRangeQuery:
{code}
[junit] NOTE: random seed of testcase
'testRandomTrieAndClassicRangeQuery_NoTrie' was: -2919237198484373178
[junit] ------------- ---------------- ---------------
[junit] Testcase:
testRandomTrieAndClassicRangeQuery_NoTrie(org.apache.lucene.search.TestNumericRangeQuery32):
FAILED
[junit] Total number of terms should be equal for unlimited precStep
expected:<668552> but was:<668584>
[junit] junit.framework.AssertionFailedError: Total number of terms should
be equal for unlimited precStep expected:<668552> but was:<668584>
[junit] at
org.apache.lucene.search.TestNumericRangeQuery32.testRandomTrieAndClassicRangeQuery(TestNumericRangeQuery32.java:266)
[junit] at
org.apache.lucene.search.TestNumericRangeQuery32.testRandomTrieAndClassicRangeQuery_NoTrie(TestNumericRangeQuery32.java:287)
[junit] at
org.apache.lucene.util.LuceneTestCase.runTest(LuceneTestCase.java:88)
[junit]
{code}
I haven't dug into it yet...
> Enable MultiTermQuery's constant score mode to also use BooleanQuery under
> the hood
> -----------------------------------------------------------------------------------
>
> Key: LUCENE-1644
> URL: https://issues.apache.org/jira/browse/LUCENE-1644
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1644.patch, LUCENE-1644.patch, LUCENE-1644.patch,
> LUCENE-1644.patch, LUCENE-1644.patch
>
>
> When MultiTermQuery is used (via one of its subclasses, eg
> WildcardQuery, PrefixQuery, FuzzyQuery, etc.), you can ask it to use
> "constant score mode", which pre-builds a filter and then wraps that
> filter as a ConstantScoreQuery.
> If you don't set that, it instead builds a [potentially massive]
> BooleanQuery with one SHOULD clause per term.
> There are some limitations of this approach:
> * The scores returned by the BooleanQuery are often quite
> meaningless to the app, so, one should be able to use a
> BooleanQuery yet get constant scores back. (Though I vaguely
> remember at least one example someone raised where the scores were
> useful...).
> * The resulting BooleanQuery can easily have too many clauses,
> throwing an extremely confusing exception to newish users.
> * It'd be better to have the freedom to pick "build filter up front"
> vs "build massive BooleanQuery", when constant scoring is enabled,
> because they have different performance tradeoffs.
> * In constant score mode, an OpenBitSet is always used, yet for
> sparse bit sets this does not give good performance.
> I think we could address these issues by giving BooleanQuery a
> constant score mode, then empower MultiTermQuery (when in constant
> score mode) to pick & choose whether to use BooleanQuery vs up-front
> filter, and finally empower MultiTermQuery to pick the best (sparse vs
> dense) bit set impl.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
