adjust query type proportion chart

[schTi]

Is your feature request related to a problem? Please describe:
We are now working with real krueger data and the structure of the returned data has changed. Thats how it looks like:

[ { "id": "momentum", "krueger_data": [ { "query_type": "SELECT", "total_latency": 18121695583, "total_frequency": 831 }, { "query_type": "CREATE", "total_latency": 286013, "total_frequency": 37 }, { "query_type": "UPDATE", "total_latency": 0, "total_frequency": 0 }, { "query_type": "INSERT", "total_latency": 0, "total_frequency": 0 }, { "query_type": "DELETE", "total_latency": 0, "total_frequency": 0 }, { "query_type": "DROP", "total_latency": 51837, "total_frequency": 37 }, { "query_type": "COPY", "total_latency": 2994107353, "total_frequency": 8 }, { "query_type": "OTHER", "total_latency": 0, "total_frequency": 0 } ] } ]

Please describe the solution you'd like:
The chart logic has to be changed to handle this data change. Additionally latency and frequency should be shown as tooltip information.

Which data should be used for the visual representation inside the chart, @Bouncner ?

Affected Component(s):
Frontend

[Bouncner]

Why not both? The should be sufficient??!?

[schTi]

Why not both? The should be sufficient??!?

What I mean is, which metric should be used to calculate the distribution displayed inside the chart? We can easily add multiple tooltip information, but the distribution should be based on one main metric, and I just wasnt sure, which one you would like to have :smile:

[Bouncner]

I think runtime is more important. @Bensk1 ?

But I was considering was to plot two stacked bar charts per database. Once with frequency, once with runtime.

[Bensk1]

In my opinion runtime is more important. I am not even sure if I would go for two bar charts at the same time. Do we have a good use case where frequency might be more helpful than runtime?

[Bouncner]

I agree, runtime is more important. But we have tons of discussions with the original Krüger et al. graph and what that the ratio of queries means for the actual workload of the database. Because even an HTAP workload with minimal OLAP load, the runtime is already dominated by reads.

And since it's not on the instance page but rather the workload page, we've got sufficient space for it. I would even put into a single plot (two bar charts, single plot ... if that works) to have them placed side-by-side.

[schTi]

I agree, runtime is more important. But we have tons of discussions with the original Krüger et al. graph and what that the ratio of queries means for the actual workload of the database. Because even an HTAP workload with minimal OLAP load, the runtime is already dominated by reads.

And since it's not on the instance page but rather the workload page, we've got sufficient space for it. I would even put into a single plot (two bar charts, single plot ... if that works) to have them placed side-by-side.

Yes that should be possible. So you still want to have a separated chart for every database?

[Bensk1]

Fine for me.

[Bouncner]

Yes that should be possible. So you still want to have a separated chart for every database?

Not sure what you mean.