[ 
https://issues.apache.org/jira/browse/LUCENE-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-2130:
--------------------------------

    Comment: was deleted

(was: Whoops - a little off in that summary - you would't apply a huge boolean 
query - you'd just have a sparser filter. This might not be that beneficial.

* edit *

Smaller, sparser filter?

*edit*

Err - in the ConstantScore mode, i guess your really just subdividing the 
filter - so no real benefit. I didn't realize it, but the constant booleanquery 
mode does still use the booleanquery (of course, why else have it) - but its 
only going to be with few clauses, so neither is really a benefit.)

> Investigate Rewriting Constant Scoring MultiTermQueries per segment
> -------------------------------------------------------------------
>
>                 Key: LUCENE-2130
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2130
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-2130.patch
>
>
> This issue is likely not to go anywhere, but I thought we might explore it. 
> The only idea I have come up with is fairly ugly, and unless something better 
> comes up, this is not likely to happen.
> But if we could rewrite constant score multi-term queries per segment, MTQ's 
> with auto, constant, or constant boolean rewrite could enum terms against a 
> single segment and then apply a boolean query against each segment with just 
> the terms that are known to be in that segment. This way, if you have a bunch 
> of really large segments and a lot of really small segments, you wouldn't 
> apply a huge booleanquery against all of the small segments which don't have 
> those terms anyway. How advantageous this is, I'm not sure yet.
> No biggie, not likely, but what the heck.
> So the ugly way to do it is to add a property to query's and weights - 
> lateCnstRewrite or something, that defaults to false. MTQ would return true 
> if its in a constant score mode. On the top level rewrite, if this is 
> detected, an empty ConstantScoreQuery is made, and its Weight is turned to 
> lateCnstRewrite and it keeps a ref to the original MTQ query. It also gets 
> its boost set to the MTQ's boost. Then when we are searching per segment, if 
> the Weight is lateCnstRewrite, we grab the orig query and actually do the 
> rewrite against the subreader and grab the actual constantscore weight. It 
> works I think - but its a little ugly.

-- 
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

Reply via email to