# Optimisations for aggregation-only requests **URL:** \ **Category:** Elasticsearch\ **Created:** [June 18, 2014, 2:29pm UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186 "2014-06-18T14:29:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [June 18, 2014, 2:29pm UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/1 "2014-06-18T14:29:43Z")
I have an elastic request that only performs aggregations. Other than setting size=0, are there other optimisations worth making? SearchType.COUNT ? -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/9e422151-7855-4e4b-ac81-0ce015bd0738%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9e422151-7855-4e4b-ac81-0ce015bd0738%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\ **Post date:** [June 18, 2014, 4:09pm UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/2 "2014-06-18T16:09:25Z")
Indeed SearchType.COUNT would work great as it would ensure that a single round-trip is performed. Other than that, if you want to filter content on which you want to aggregate, make sure to put it in a filtered query as opposed to a filter aggregation: since aggregations are executed on every matching document, this would evaluate the filter against every document (since the default query, match\_all, matches them all) while if you put the filter in the query, elasticsearch would be able to quickly skip over non-matching documents. -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j5pjEWsMX3zZiUJLcyW3d77CzV6jd83AT7A6xRRLX-PHQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j5pjEWsMX3zZiUJLcyW3d77CzV6jd83AT7A6xRRLX-PHQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [June 18, 2014, 4:21pm UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/3 "2014-06-18T16:21:26Z")
Hm, Interesting. I currently make one request that performs multiple aggregations. All my aggregations have a filter aggregation as the top level item (all are different). Do you think it would be better performance executing multiple requests with a filterQuery instead? On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote: > Indeed SearchType.COUNT would work great as it would ensure that a single > round-trip is performed. Other than that, if you want to filter content on > which you want to aggregate, make sure to put it in a filtered query as > opposed to a filter aggregation: since aggregations are executed on every > matching document, this would evaluate the filter against every document > (since the default query, match\_all, matches them all) while if you put the > filter in the query, elasticsearch would be able to quickly skip over > non-matching documents. -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/a98bc623-3b20-46be-8594-8b252e66658f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/a98bc623-3b20-46be-8594-8b252e66658f%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [June 18, 2014, 4:22pm UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/4 "2014-06-18T16:22:12Z")
Mind you, I only have 10's of thousands of documents I am aggregating over... maybe the perf difference is negligible? On Wednesday, 18 June 2014 17:21:26 UTC+1, mooky wrote: > Hm, Interesting. > I currently make one request that performs multiple aggregations. All my > aggregations have a filter aggregation as the top level item (all are > different). > Do you think it would be better performance executing multiple requests > with a filterQuery instead? > > On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote: > > > Indeed SearchType.COUNT would work great as it would ensure that a single > > round-trip is performed. Other than that, if you want to filter content on > > which you want to aggregate, make sure to put it in a filtered query as > > opposed to a filter aggregation: since aggregations are executed on every > > matching document, this would evaluate the filter against every document > > (since the default query, match\_all, matches them all) while if you put the > > filter in the query, elasticsearch would be able to quickly skip over > > non-matching documents. -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\ **Post date:** [June 19, 2014, 12:12am UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/5 "2014-06-19T00:12:55Z")
If the union of the documents that match all your filters is much smaller than your whole dataset then it would indeed help to run separate queries (potentially in a multi search call). On Wed, Jun 18, 2014 at 6:22 PM, mooky [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > Mind you, I only have 10's of thousands of documents I am aggregating > over... maybe the perf difference is negligible? > > On Wednesday, 18 June 2014 17:21:26 UTC+1, mooky wrote: > > > Hm, Interesting. > > I currently make one request that performs multiple aggregations. All my > > aggregations have a filter aggregation as the top level item (all are > > different). > > Do you think it would be better performance executing multiple requests > > with a filterQuery instead? > > > > On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote: > > > > > Indeed SearchType.COUNT would work great as it would ensure that a > > > single round-trip is performed. Other than that, if you want to filter > > > content on which you want to aggregate, make sure to put it in a filtered > > > query as opposed to a filter aggregation: since aggregations are executed > > > on every matching document, this would evaluate the filter against every > > > document (since the default query, match\_all, matches them all) while if > > > you put the filter in the query, elasticsearch would be able to quickly > > > skip over non-matching documents. > > > > -- > > 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). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- Adrien Grand -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j47UZ8tyy\_B7jgC3aiwo5b8cM7iearFTO4PdxaoVnXB6w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j47UZ8tyy_B7jgC3aiwo5b8cM7iearFTO4PdxaoVnXB6w%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 1:21am UTC](https://discuss.elastic.co/t/optimisations-for-aggregation-only-requests/18186/6 "2017-07-06T01:21:24Z")