Yes Erick. Correctly pointed.
Thanks,
Sriram
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-And-query-tp4166685p4166789.html
Sent from the Solr - User mailing list archive at Nabble.com.
U. That may be true for your particular example data set, but not
in the general case, so don't be fooled.
q.op=AND is equivalent to
q=f1:(word1 AND word2) AND f2:(word3 AND word4) AND f3:(word5 AND word6)
This query
q=f1:"word1 word2" AND f2:"word3 word4" AND f3:"word5 word6"
would not match
Thanks Eric. I tried q.op=AND and noticed that it is equivalent to
specifying,
q=f1:"word1 word2" AND f2:"word3 word4" AND f3:"word5 word6"
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-And-query-tp4166685p4166760.html
Sent from the Solr - User mailing list archive at
Right, but do be aware of one thing. The form
f1:(word1 word2) has an implicit OR between them
based on "q.op" which is specified in your
solrconfig.xml file for the request handler you're
using.
This is no problem, but if you ever specify "q.op" as AND
either in solrconfig.xml or as an explicit p
Actually I found out how to form the query. I just need to use,
q=f1:(word1 word2) AND f2:(word3 word4) AND f3:(word5 word6)
Thanks,
V.Sriram
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-And-query-tp4166685p4166744.html
Sent from the Solr - User mailing list archiv
We are working on optimizing query performance. My concern was to ensure
some stable QoS. Given our API and UI layout, user may generate an
expensive query. Given the nature of the service, user may want to
"hack" it. Currently, our Search API is a good point to try to inflict
DoS on our server
The first thing I'd do is run your query with &debguQuery=on and look
at the "timings" section. That'll tell you what component is taking all
the time and should help you figure out where the problem is
But worst-case you could implement a custom component to stop
processing after some set num