this looks unnecessary nice all joins are LEFT and it's a primary unique key.

Hmm, after removing that ` group by` from the query, I'm not seeing a speed improvement in the console for /jobs/ calls while loading the page. However, so far, I'm seeing an INCREASE in web transaction time in mysql on stage. I'll attach a couple screenshots. But on prod (not running the changed code) the max web transaction time is around 50ms. On stage (with the change) the peaks are close to 200ms. This is making me think we should not implement this change. But still investigating.

stage, of course, has much less traffic, so it's more sawtooth. But I would expect the peaks to be equivalent. I'll revert stage to master and ensure it has peaks more in-line with production.

Hrm.. Pushed master back to stage and got about the same results as stage before: Peaks of ~200ms. I realized that we exclude MANY more jobs on prod. So I tried the UI calls without excluding jobs. Still, prod doesn't hit those peaks, but stage does. I'm inclined to think the change is having little to no effect. But I'm going to sit on this for a bit to see if I come up with a better idea on the cause of the results I'm seeing.

I have a hard time believing that removing the group by would have a negative effect on performance, but depending on how MySQL works internally (it probably does caching of some kind?) I could believe it might not have much in the way of positive impact.

We stopped grouping this way when we switched to querying the Django ORM for this data.