Optimisations for aggregation-only requests

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/9e422151-7855-4e4b-ac81-0ce015bd0738%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j5pjEWsMX3zZiUJLcyW3d77CzV6jd83AT7A6xRRLX-PHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a98bc623-3b20-46be-8594-8b252e66658f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3c70ebe3-2dcc-4882-bfe3-effa6bbfdb48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 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.
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?utm_medium=email&utm_source=footer
.

For more options, visit 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAL6Z4j47UZ8tyy_B7jgC3aiwo5b8cM7iearFTO4PdxaoVnXB6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.