my guess is so that you are able to have multiple, separate, "groups" and operate on them all within the same query

@planetscale???

Window functions are a great way to compute running totals, averages, sums, etc. Or do something specific with the first or last row. Or peek at the next row or the previous row within a group. Or group by different things within a single query. They're very powerful!

@@PlanetScale yes but this specific task would be better with group by. still a great thing to know

in this case it could be done with groupby right? Or im missing something?

Haha didn't even think about it

Multi master is so much fun 🤔😬

My thoughts exactly as well :P Probably could even do `GROUP BY bucket ORDER BY bucket`

For the aggregations a simple group by should work as well. It would complicate the query in case you actually need the fields for first- and last timestamp (although one could be calculated back from the bucket). In the end using window functions was most likely the more interesting and educational topic for a video, even though the simple example could be solved in other ways

@@goaserer I think it’s more like a leading video for the summary tables topic. I recently worked on a topic like this so I keep seeing group by solutions everywhere I look.

@@developertpl I agree that showing window functions approach here is a nice educational approach. However, since it was mentioned that it is a no go for PlanetScale, it would be nice to also show the group by approach as an alternative here. Especially after we filtered only last record of each bucket which is literally what would group by achieve. From my point of view window functions are best used when you're reviewing per-record data in context of its group/bucket, which wasn't the case here. Tl;dr I enjoyed the video and always appreciate videos on this channel as they are of high quality and very informative. Just pointing out showing group by approach as well would make it "whole" :)

@@Szarlus Great content for sure! Always a pleasure.

Bump! I was thinking the same.

It is faster First, you don't pull tens of thousands of rows over the network Second, even if MySQL is not optimized for timeseries data, it is still dozen of times faster than say, Javascript or Java. After you got the grouped result which has reduced size, then you pull that data to application level and display them as charts

@@_MB_93 But, will it create another bottleneck elsewhere? I mean, database connection is a resource. Will performing calculation hold those connections? Because if it is, then wouldn't it be better to just dump data and then perform calculation on the application side since the application server is typically easier to scale than db server? But of course, this also needs to be performed after profiling.

@@YandiBanyu It is a bottleneck no matter where you put it, its just that database is a specialized software for aggregating and transforming data, I personally think it is "re-inventing the wheels" if things such as "group by" is performed on application side. As for scaling, well, as Aaron said in the video, MySQL can take you a long long way before you actually need it.

@@_MB_93 yeah, there will always be bottleneck somewhere. But some of it is easier to solve than others. I agree that not many applications will scale beyond what RDBMS such as MySQL offer, but it is still good to keep in mind too when doing costly operations on the database level. After all, it is (IMHO) harder to reduce the bottleneck of a single database server (before going to a more complex clustering strategy) than say, spin up another server instance behind a load balancer. This can matter when making an application that needs on premise data for some security/legal reasons.

😅😂😂😂😂