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.