Aidan Oldershaw

Appreciate those details. Interesting how different our own insights look. One thought - the bigint migrations leaves a ton of bloat in the DB. We ended up running a VACUUM...

@simonjohansson thanks for checking that - an improvement, but there's probably a bigger culprit (probably that `SELECT b.id, b.name, ...` query still). Speaking of, have the insights on that query...

@simonjohansson thanks for confirming. Taking a look into how we can optimize that query. No worries if not, but would you be willing to add a temporary index to your...

@simonjohansson hm, that's unfortunate. @clarafu suggested a better index than the one I gave: ``` CREATE INDEX deleteme ON builds (job_id, COALESCE(rerun_of, id) DESC, id DESC) WHERE job_id IS NOT...

@simonjohansson Good to know, thanks! Curious to see if that query is still the primary source of slowness after running for a while. Overall, we suspect that builds for checks...

> first one is `UTILITY COMMAND`, unclear what that is but I think it's GCP SQL related Yeah, not sure what we can do about that to be honest. Nice...

7.2.0 is out now with the new index and a slight optimization to creating check builds - I'd be curious to see what impact it has on your deployments when...

Doesn't look like this is related to #5753 or #5620 - it affects 6.1 as well (and looking at the git history, looks like this issue's probably been around for...

I was running into this as well, and for a little while assumed the fuzzer was just running out of memory (as the `SUMMARY` suggests), but was completely neglecting the...

@tech-geek29 I just approved your request to join contributors in https://github.com/concourse/governance (welcome!) - can you try to add the label again? EDIT: you may have to approve an invitation, let...