I do, but not on this Query... the same happens when I use Luke
----- Original Message ---- > From: Uwe Schindler <u...@thetaphi.de> > To: java-user@lucene.apache.org > Sent: Wednesday, 15 July, 2009 22:37:04 > Subject: RE: speed of BooleanQueries on 2.9 > > 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 > > 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 > > > McCandlesswrote: > > >> On Wed, Jul 15, 2009 at 2:30 PM, eks devwrote: > > >>> > > >>>> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
