And the fix only affects custom DocIdSetIterators. The ones from Lucene core all implement the new API and do it more effective than the example code :-)
Or does Eks Dev use custom DocIdSetIterators? Uwe ----- 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, July 15, 2009 10:25 PM > To: java-user@lucene.apache.org; yo...@lucidimagination.com > Subject: Re: speed of BooleanQueries on 2.9 > > I just committed Uwe's fix for that (thanks Uwe!), but I don't think > it's causing eks' slowdown because eks' case is a straight OR query, > which doesn't use advance. > > Mike > > On Wed, Jul 15, 2009 at 3:23 PM, Yonik Seeley<yo...@lucidimagination.com> > wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
