You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by briand <br...@gmail.com> on 2008/07/23 20:28:49 UTC
performance implications on using lots of values in fq
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.
Re: performance implications on using lots of values in fq
Posted by Norberto Meijome <fr...@meijome.net>.
On Wed, 23 Jul 2008 11:28:49 -0700 (PDT)
briand <br...@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.
Hey Brian,
sorry, i can't answer your question. but I wonder if you tried Postgresql + PostGis extensions, and what has your experience been, compared to Lucene/SOLR.
thanks :)
b
_________________________
{Beto|Norberto|Numard} Meijome
Computers are like air conditioners; they can't do their job properly if you open windows.
I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
Re: performance implications on using lots of values in fq
Posted by Preetam Rao <bl...@gmail.com>.
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 <br...@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.
>
>