Good point! Queries that timeout can be lengthy nested boolean queries so perhaps there's some other approach besides checking for each hit and minimize CPU usage?
On Wed, Jun 24, 2009 at 2:25 AM, Earwin Burrfoot <ear...@gmail.com> wrote: > Having scorers check timeouts while advancing will definetly increase > the frequency of said timeouts. > > On Wed, Jun 24, 2009 at 13:13, eks dev<eks...@yahoo.co.uk> wrote: > > Re: "I think such a parameter should not exist on individual search > methods > > since it's more of a global setting (i.e., I want my searches to be > limited > > to 5 seconds, always, not just for a particular query). Right?" > > > > I am not sure about this one, we had cases where one phisical index > served > > two logical indices with different requirements for clients. having > Timeout > > settable per Query is nice to have. > > > > At the end of day, with such timeout you support Quality/Time compromise > > settings: > > "if you need all results, be ready to wait longer and set longer timeout" > > "if you need SOME results quickly than reduce this timeout" > > > > that should be idealy user decision > > > > ________________________________ > > From: Shai Erera <ser...@gmail.com> > > To: java-dev@lucene.apache.org > > Sent: Wednesday, 24 June, 2009 10:55:50 > > Subject: Re: Improving TimeLimitedCollector > > > > But TimeLimitingCollector's logic is coded in its collect() method. The > top > > scorer calls nextDoc() or advance() on all its sub-scorers, and only when > a > > match is found it calls collect(). > > > > If we want the sub-scorers to check whether they should abort, we'd need > to > > revamp (liked the word :)) TimeLimitingCollector, to be something like > > CheckAbort SegmentMerger uses. I.e., the top scorer will pass such an > > instance to its sub scorers, which will call a TimeLimit.check() or > > something and if the time limit has expired this call will throw a > > TimeExceededException (like TLC). > > > > We can enable this by adding another parameter to IndexSearcher whether > > searches should be limited by time, and what's the time limit. It will > then > > instantiate that object and pass it to its Scorer and so on. I think such > a > > parameter should not exist on individual search methods since it's more > of a > > global setting (i.e., I want my searches to be limited to 5 seconds, > always, > > not just for a particular query). Right? > > > > Another option would be to add a setTimeout method on Query, which will > use > > it when it constructs its Scorer. The shortcoming of this is that if I > want > > to use someone else's query which did not implement setTimeout, then I'll > > need to build a TimeOutQueryWrapper that will wrap a Query, and implement > > the timeout logic, but that's get complicated. > > > > I think the Collector approach makes the most sense to me, since it's the > > only object I fully control in the search process. I cannot control Query > > implementations, and I cannot control the decisions made by > IndexSearcher. > > But I can always wrap someone else's Collector with TLC and pass it to > > search(). > > > > Shai > > > > On Wed, Jun 24, 2009 at 12:26 AM, Jason Rutherglen > > <jason.rutherg...@gmail.com> wrote: > >> > >> As we're revamping collectors, weights, and scorers, perhaps we > >> can push time limiting into the individual subscorers? Currently > >> on a boolean query, we're timing out the query at the top level > >> which doesn't work well if the subqueries exceed the time limit. > > > > > > > > > > -- > Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
