Timeseries vs GroupBy performance

I understand that TimeSeries queries are much faster than GroupBy. However it is unclear as to:

1. By how much faster are they? Is it an order of magnitude difference?
I understand that this may depend on many factors of the GroupBy query, but what are those factors?

2. I understand that one can use multiple timeSeries queries to get the same result as a single GroupBy query.
However, at what point doing multiple Timeseries queries become the same cost or costlier than just doing a single GroupBy?

Inline.

I understand that TimeSeries queries are much faster than GroupBy. However it is unclear as to:

  1. By how much faster are they? Is it an order of magnitude difference?

Timeseries == groupby with no dimensions. The performance is likely an order of magnitude different.

I understand that this may depend on many factors of the GroupBy query, but what are those factors?

  1. I understand that one can use multiple timeSeries queries to get the same result as a single GroupBy query.

However, at what point doing multiple Timeseries queries become the same cost or costlier than just doing a single GroupBy?

I don’t think you ever need multiple timeseries queries to do a single groupBy query. If you are issuing a groupby with no dimensions, it is equivalent to a timeseries query.

Fangjin,
Correct me if i am wrong here:

If i have a groupby where i order by a dimenstion, say ‘metric name’.

Since I know ‘metric name’ can have only 3 different values, I have 2 choices:

  1. issue 3 timeseries queries, where i put in a filter for the specific metric name
  2. issue a single groupby query where i specify ‘metricname’ as the dimension
    In this case, will option 1 be faster than 2?

If yes, then at what point will option 1 start to be become slower than 2, Eg - is it when the ‘metricname’ can have 20 different values, so we do 20 different timeseries queries?

Hi Prashant, we’re not sure where the inflection point would be for your example. It would be interesting to do an evaluation. For that particular use case, it sounds like a topN query is what you need.