To correctly implement the backwards-pattern, it should call skipTo: public int advance(int target) throws IOException { return doc = skipTo(target) ? doc() : NO_MORE_DOCS; }
This is how nextDoc is implemented. New iterator that override advance() work correct, older ones implementing skipTo would work with this method. In my opinion, this should be changed, the pattern is wrong. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik > Seeley > Sent: Wednesday, July 15, 2009 9:23 PM > To: java-user@lucene.apache.org > Subject: Re: speed of BooleanQueries on 2.9 > > Could this perhaps have anything to do with the changes to > DocIdSetIterator? > Glancing at the default implementation of advance makes me wince a bit: > > public int advance(int target) throws IOException { > while (nextDoc() < target) {} > return doc; > } > > IMO, this is a back-compatibility anti-pattern. It would be better to > throw an exception then quietly slow down some of the users queries by > an order of magnitude. Actually, I don't think I would count it as > back compatible because of that. > > -Yonik > http://www.lucidimagination.com > > > > On Wed, Jul 15, 2009 at 2:54 PM, Michael > McCandless<luc...@mikemccandless.com> wrote: > > On Wed, Jul 15, 2009 at 2:30 PM, eks dev<eks...@yahoo.co.uk> wrote: > >> > >>> Weird. Have you run CheckIndex? > >> nope, I guess it brings nothing: two times built index; Bug provoked by > changing one parameter that controls only search caused it => no corrupt > index? > >> > >> You think we should give it a try? Hell, why not :) > > > > Yah it's quite a long shot but if it is corrupt, we'll be kicking > > ourselves about 30 emails from now... > > > >> What do you mean by "Can you do a binary search to locate the term(s) > that's causing it?" > >> > >> I know exactly which term combination causes it, last Query.toString() > I have sent.... if I simplify Query by dropping one term with its > expansions, it runs fine... or if I replace any of these terms it works > fine,We tried with higer freq. terms, lower... everything fine... bizzar > > > > Right I meant try to whittle down the query that tickles the infinite > > loop. Sounds like any whittling causes the issue to scurry away. > > > > If I make a patch that adds verbosity to what BS is doing, can you run > > it & post the output? > > > > Mike > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org