I don't have much idea on performance of these many fqs, since I have usually used very small number of fqs. But passing my thoughts hoping it might help. (since I did not see any response :-)
a) the filter cache size needs to be more, so that fqs can be cached. If a fq is not in cache, AFAIK, each fq produces one lucene query. b) If fqs are in cache, the operations involving fq reduces to intersecting the N bit sets where N is number of fqs. In the worst case, N fqs boil down to N lucene queries and N bitset intersections. Just a wild guess - if you are doing something with radius search or similar search involving lat/longs, you can try using LocalSolr, which takes care of all the details for you. ------ Preetam On Wed, Jul 23, 2008 at 11:58 PM, briand <[EMAIL PROTECTED]> wrote: > > I have documents in SOLR such that each document contains one to many > points > (latitude and longitudes). Currently we store the multiple points for a > given document in the db and query the db to find all of the document ids > around a given point first. Once we have the list of ids, we populate the > fq with those ids and the q value and send that off to SOLR to do a search. > In the "longest" query to SOLR we're populating about 450 ids into the fq > parameter at this time. I was wondering if anyone knows the performance > implications of passing so many ids into the fq and when it would > potentially be a problem for SOLR? Currently the query passing in 450 ids > is not a problem at all and returns in less than a second. Thanks. > -- > View this message in context: > http://www.nabble.com/performance-implications-on-using-lots-of-values-in-fq-tp18617397p18617397.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
