lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Preetam Rao" <blogathan....@gmail.com>
Subject Re: performance implications on using lots of values in fq
Date Thu, 24 Jul 2008 10:44:13 GMT
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 <brianpdoyle@gmail.com> 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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message