lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <DOR...@il.ibm.com>
Subject Re: [jira] Resolved: (LUCENE-730) Restore top level disjunction performance
Date Thu, 19 Apr 2007 23:42:57 GMT
Chris Hostetter <hossman_lucene@fucit.org> wrote on 19/04/2007 16:01:53:

>
> : With this committed it also makes sense to deprecate the
setUseScorer14()
> : method and the corresponding get...() method. If you want a patch for
that,
> : I'll gladly provide one.
>
> i haven't really been able to follow this issue as much as i would like,
> but docs now sometimes coming out of order and the need to hobble
> QueryUtils.check(Query,Searcher) because of this alarms me a bit ... i
> can't really think of all the cases this might cause problems for people,
> but i'm, sure there may be some (i remember it was kind of a big deal
when
> BooleanScorer2 came out and people could start relying on docs coming in
> order ... it's why ConstantScoreRangeQuery because a wrapper arround
> ConstantScoreQuery -- the first version i wrote collected dos in order
> they were found while walking the TermEnum/TermDocs and people didn't
like
> that this ment they weren't in order)
>
> perhaps this patch should be changed to only have this effect
> (BooleanScorer2 delegating to BooleanScorer) only if
> BooleanQuery.setUseScorer14(true) has been called -- and the existing use
> of BooleanQuery.getUseScorer14() to decide between BooleanWeight and
> BooleanWeight2 can be removed (and BooleanWeight can be deprecated)
>
> that way people who are okay with getting docs out of order can call
> BooleanQuery.setUseScorer14(true) and get the performance benefits when
> possible, but people who want to be sure they get documents in order have
> to accept that in some cases their queries arent' as fast asthey could
be.
>
> ...i believe what i'm suggesting would keep the fundemental meaning of
> setUseScorer(true), even if the value is now used in a slightly differnet
> place ... correct?

Amazing timing! - just as I was working at 697 trying to un-cancel the
checking skipTo...

This suggestion would help in 697 of course, but I think it also makes
sense in general.

Could I modify it a little - to something more general than "use scorer
number J" - perhaps something like:
   void allowDocsOutOfOrer(boolean allow);
   boolean isAllowedDocsOutOfOrder();
Also, it would be nice to make this a (non static) method of Query, and, I
think, also of Weight and Scorer (Weight would "like-inherit" that property
from its Query, and Scorer from its Weight). The default would be
"disallowed", and the documentation would say that allowing may enable
further optimization, though in some cases (like currently non boolean
scorers or ones with more than 32 prohibited sub scorers) this might have
no effect at all.

Doron


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message