Small Feature Request: Add a flag to prevent aggs and postAggs from being sent back. about druid

[vogievetsky]

How are we treating issues that still make sense for native Druid queries but are solved by DruidSQL? Probably can be closed right?

[stale]

This issue has been marked as stale due to 280 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.

[stale]

This issue is no longer marked as stale.

[reemasaluja]

@vogievetsky , any update on this ticket?

[cswarth]

I'd love to see some movement on this issue (unless I'm missing some way to suppress aggregations in native queries).
I'm aggregating over large objects then applying a post aggregator to produce a small derived metric. The aggregated objects can be quite large when base64 encoded in the response (like 80K+) and I don't actually need them in the response.

[benkrug]

I haven't tried yet, but is it possible to wrap the query into an inner query, and select the desired fields from that in an outer query? (As a workaround until there's a flag.)

[Fryuni]

We're having the same problem.
For now most of our queries are wrapped on secondary queries just to hide the intermediary fields, but not all query types can be wrapped in other queries (e.g. the movingAverage query).

Some of our queries are timeseries with about 240 entries and each entry contains a 50KB thetaSketch that is generate by an intersection postAgg that we need. That is 12MB of useless data for each chart on our dashboards while the actual data is less than 2KB.

DruidSQL is not a solution since it does not support many of the agg and postAgg that we use (some from extensions that may not even try to support DruidSQL)

[jrobin42]

Same thing here, especially when using the second as granularity, unused fields waste too much bandwidth. Is anyone working on this issue ? Thanks !

[github-actions]

This issue has been marked as stale due to 280 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If this issue is still
relevant, please simply write any comment. Even if closed, you can still revive the
issue at any time or discuss it on the [email protected] list.
Thank you for your contributions.

[github-actions]

This issue has been closed due to lack of activity. If you think that
is incorrect, or the issue requires additional review, you can revive the issue at
any time.

[Fryuni]

AFAICT this is still a problem with only the whacky workaround mentioned before