Adding filter query slows down avg response time

[nutchsolruser <nu...@gmail.com>]

I am finding users with same nick name in certain area. when i send both
queries in q parameter to solr it works really fast . but if i send location
query in fq then it slows down too much. why it is so? why adding fq to
query degrades my performance?

nickname:"nick name"
{!geofilt pt=20.2284,80.2284 sfield=ps_lat_long d=4}



--
View this message in context: http://lucene.472066.n3.nabble.com/Adding-filter-query-slows-down-avg-response-time-tp4120555.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Adding filter query slows down avg response time

[nutchsolruser <nu...@gmail.com>]

Found and here,
may be it's because my filter query is changing for each new user. Better i
keep it in main query
http://lucene.472066.n3.nabble.com/fq-vs-q-td495570.html



--
View this message in context: http://lucene.472066.n3.nabble.com/Adding-filter-query-slows-down-avg-response-time-tp4120555p4120559.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Adding (spatial) filter query slows down avg response time

["David Smiley (@MITRE.org)" <DS...@mitre.org>]

Hi,

The reason why it's working faster for you when you put {!geofilt} into your
main query is most likely because the particular field type you are using is
LatLonType, which works on a per-document basis, and by putting it in the
main query it will, by default, leap-frog across the documents with the
other part of your main query (nickname).  But that said, neither of your
attempts are doing it the right way.

If you have reason to believe that this particular spatial query isn't going
to be very cacheable, then use PostFilter'ing.  You simply use it in a
filter query, but add cache=false and cost=100 local-params.  This will
ensure that it's evaluated *last* (because we know it's slow).  If your main
query is *:* or otherwise matches a ton of stuff, then you're still screwed,
though.

If you think your spatial query might be cacheable, then use "location_rpt"
in the default schema for the filter.  The field type is a mouth full by I
abbreviate it to simply RPT. (recursive prefix tree).  This does *not*
operate per-document like LatLonType; how fast it works will depend roughly
on how densely populated there exists indexed points towards the edge of the
query shape (i.e. in the last ~5% of the distance from the center).  But
it's basically very fast.

But RPT is so fast that I suggest you give it a shot even if you think the
query isn't cacheable and let me know how fast you think it is compared to
PostFiltering.  Such a performance shoot-out will be extremely dependent on
a variety of factors.  For example if your nickname query and other filters
are extremely selective and only match a handful of documents, then nothing
is going to be faster than post-filtering because it only needs to compute
the distance a handful of times.  But it you can't predict how selective it
might be; it might be anything including matching a ton of stuff, then RPT
is going to be fairly consistent in its performance, and I believe generally
faster.  Personally I'd take consistently fast versus an option that is
sometimes the fastest but sometimes terrible.  Wouldn't you?

~ David
p.s. next time if you ask a question about spatial/geospatial then use such
words and I will notice it faster


nutchsolruser wrote
> I am finding users with same nick name in certain area. when i send both
> queries in q parameter to solr it works really fast . but if i send
> location query in fq then it slows down too much. why it is so? why adding
> fq to query degrades my performance?
> 
> nickname:"nick name"
> {!geofilt pt=20.2284,80.2284 sfield=ps_lat_long d=4}





-----
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Adding-filter-query-slows-down-avg-response-time-tp4120555p4120662.html
Sent from the Solr - User mailing list archive at Nabble.com.