# Elasticsearch polygon filter performance **URL:** \ **Category:** Elasticsearch\ **Created:** [November 18, 2013, 2:36pm UTC](https://discuss.elastic.co/t/elasticsearch-polygon-filter-performance/14449 "2013-11-18T14:36:03Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![shmish111](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shmish111/32/950_2.png) [@shmish111](https://discuss.elastic.co/u/shmish111)\ **Post date:** [November 18, 2013, 2:36pm UTC](https://discuss.elastic.co/t/elasticsearch-polygon-filter-performance/14449/1 "2013-11-18T14:36:03Z")
I have been playing around with the polygon filter on our index and with the desired accuracy of the polygon on 2 million documents i'm getting search times of 200-300ms at best. I've yet to add a bounding box filter as I hear that will speed things up a bit but my question is, will adding a load of nodes speed things up? I really need to get under 100ms. This is for a high traffic site, presumably if we start doing polygonsearches like this is it likely that the cluster performance as a whole will suffer badly as well? Also, what is the point of setting geohash on the geo\_point type, is this just so you can search against the geohashvalue yourself or does it affect performance in any way? Loving the geospatial stuff, we just need to fiddle a bit more before it's production useable. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:06am UTC](https://discuss.elastic.co/t/elasticsearch-polygon-filter-performance/14449/2 "2017-07-06T02:06:25Z")