Option to remove key_as_string from aggregation response

[wylieconlon]

Formatted keys are not always needed when the original value is used by client code, but are always returned. If there were an option to remove the formatted values then we could reduce the total response size of ES queries by going from this type of response:

{
  ...
  "aggregations": {
    "sales_over_time": {
      "buckets": [
        {
          "key_as_string": "2015-01-01",
          "key": 1420070400000,
          "doc_count": 3
        },

to this:

{
  ...
  "aggregations": {
    "sales_over_time": {
      "buckets": [
        {
          "key": 1420070400000,
          "doc_count": 3
        },

One option that would be nice would be to have a parameter called "include_formatted": false on the date histogram and other aggregations that return formatted keys.

There are existing workarounds, but both workarounds have issues:

• Using REST response filtering to remove the keys. This has issues because of a bug in response filtering.
• Setting the format to a special character like _ will reduce some of the response size, but the response will still contain "key_as_string": "_" instead of being removed.

cc @polyfractal

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

[alishahusain]

I'm a first time contributor to this project and would like to take on this issue

[javanna]

Just an idea: would it make sense to implement this based on the human flag that every API already supports?

[nik9000]

Just an idea: would it make sense to implement this based on the human flag that every API already supports?

I think that'd be breaking change. Its a good idea though!

It looks like we always have a guard for emitting these like if format != RAW {b.field("key_as_string", format.format(key)}. Maybe we already support this and you just have to request the raw format everywhere? I'm not sure if there is a way to request the raw format everywhere though. I'm willing to bet some of those guards were just copy and pasted from other aggs.

[javanna]

I think that'd be breaking change. Its a good idea though!

I see, because the human flag has a global default which is false and that would change the default behaviour of aggs.

[akshataj96]

Hi @wylieconlon @javanna ,
I can see that there are too many references for "key_as_string".
Can you give me some start point so that i can look further into this?

[not-napoleon]

@akshataj96 & @alishahusain - As we looked deeper into this as a team, we found more complexity than we initially thought, and we've decided we need to address this internally. Sorry that we were a little too optimistic in labeling it good first issue. I encourage you to keep looking for issues you'd like to work on though!

[elasticsearchmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)