Hi, Probably because the [NOW/DAYS-7DAYS+TO+NOW] part gets rewritten as lots of OR clauses. I think that you'll see that if you add &debugQuery=true to the URL. Make sure your recorded_date_dt is not too granular (e.g. if you don't need minutes, round the values to hours. If you don't need hours, round the values to days).
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Yongjun Rong <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Tuesday, June 17, 2008 11:56:06 AM > Subject: RE: Search query optimization > > Hi, > Thanks for your reply. I did some test on my test machine. > http://stage.boomi.com:8080/solr/select/?q=account:1&rows=1000. It will > return resultset 384 in 3ms. If I add a new AND condition as below: > http://stage.boomi.com:8080/solr/select/?q=account:1+AND+recordeddate_dt > :[NOW/DAYS-7DAYS+TO+NOW]&rows=1000. It will take 18236 to return 21 > resultset. If I only use the recordedate_dt condition like > http://stage.boomi.com:8080/solr/select/?q=recordeddate_dt:[NOW/DAYS-7DA > YS+TO+NOW]&rows=1000. It takes 20271 ms to get 412800 results. All the > above URL are live, you test it. > > Can anyone give me some explaination why this happens if we have the > query optimization? Thank you very much. > Yongjun Rong > > > -----Original Message----- > From: Walter Underwood [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 29, 2008 4:57 PM > To: solr-user@lucene.apache.org > Subject: Re: Search query optimization > > The people working on Lucene are pretty smart, and this sort of query > optimization is a well-known trick, so I would not worry about it. > > A dozen years ago at Infoseek, we checked the count of matches for each > term in an AND, and evaluated the smallest one first. > If any of them had zero matches, we didn't evaluate any of them. > > I expect that Doug Cutting and the other Lucene folk know those same > tricks. > > wunder > > On 5/29/08 1:50 PM, "Yongjun Rong" wrote: > > > Hi Yonik, > > Thanks for your quick reply. I'm very new to the lucene source code. > > Can you give me a little more detail explaination about this. > > Do you think it will save some memory if docnum = find_match("A") > > > docnum = find_match("B") and put B in the front of the AND query like > > "B AND A AND C"? How about sorting (sort=A,B,C&q=A AND B AND C)? Do > > you think the order of conditions (A,B,C) in a query will affect the > > performance of the query? > > Thank you very much. > > Yongjun > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik > > Seeley > > Sent: Thursday, May 29, 2008 4:12 PM > > To: solr-user@lucene.apache.org > > Subject: Re: Search query optimization > > > > On Thu, May 29, 2008 at 4:05 PM, Yongjun Rong > > wrote: > >> I have a question about how the lucene query parser. For example, I > >> have query "A AND B AND C". Will lucene extract all documents satisfy > > >> condition A in memory and then filter it with condition B and C? > > > > No, Lucene will try and optimize this the best it can. > > > > It roughly goes like this.. > > docnum = find_match("A") > > docnum = find_first_match_after(docnum, "B") docnum = > > find_first_match_after(docnum,"C") > > etc... > > until the same docnum is returned for "A","B", and "C". > > > > See ConjunctionScorer for the gritty details. > > > > -Yonik > > > > > > > >> or only > >> the documents satisfying "A AND B AND C" will be put into memory? Is > >> there any articles discuss about how to build a optimization query to > > >> save memory and improve performance? > >> Thank you very much. > >> Yongjun Rong > >>
