-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to retrieve in an aggregations request only pipeline aggs results #15823
Comments
@acarstoiu Use response filtering to return just the aggs that you want. See https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#_response_filtering |
Yes, I found this on my own in June last year, see this comment. But that's just a workaround, isn't it?! |
@acarstoiu Me to need this feature. |
Use a pipeline aggregation and follow the @clintongormley's link. |
@acarstoiu thanks. this do solve my problem |
Off topic: please stop using a mechanical translator and learn the language. English has by far the simplest grammar among the European languages, it's the best you can get in terms of simplicity (and I know the Chinese grammar is way simpler). And now to the matter: yes, it is less than optimal, that's why this issue exists (albeit closed - @clintongormley has yet to explain why). |
@acarstoiu kindly refrain from castigating other users about their level of English. |
Well, I did ponder whether to write that or not, but I honestly believe it helps the guy a lot more than being "politically correct", a term invented in the west. Try using a mechanical translator for un șut în fund înseamnă un pas înainte ✌️ |
@acarstoiu @clintongormley thanks a lot for your kindness.I'll improve my English although I was not using google translator.so embarrassing. |
I have explained this matter in several other issues, but it's time to make it a ticket on its own.
Very often programmers find themselves in the need to post-process the aggregation results computed by Elasticsearch. Since October 2015 the pipeline aggregations are officially avaliable to everyone, so a bunch of use cases can now be handled by just crafting a more elaborate search query.
That's very good, but not enough yet, because clients need also to be off-loaded in terms of network traffic and memory. For now, they receive and are forced to load from the network reply the results of +completely uninteresting+, intermediate aggregations.
Ideally, we should have control on the aggregation level whether its results should be returned or not (a
prune
property accepted by all aggregations would be just fine). Alternatively, one could also prune from the results the aggregations used in pipeline aggregations via a search-wide flag called (say)prunePipelinedAggs
with three possible values:false
: default, for backwards compatibility (but I would vote forbasic
as default value)basic
: suppresses only the results of basic aggregations that serve as source data for pipeline aggs; the results of "unrefined" aggregations remain untouched, in the replyall
: suppresses the results of all aggregations (both basic and pipeline) that serve as source data for pipeline aggsWording may vary, but you get the idea. Particularly "basic" is not an established term.
The text was updated successfully, but these errors were encountered: