Simon Johansson

@aoldershaw * 1702 pipelines (203 paused) * 8917 jobs * 2119708 builds  So no IO wait. 

> One thought - the bigint migrations leaves a ton of bloat in the DB. We ended up running a VACUUM FULL VERBOSE ANALYZE after upgrading, but this takes a...

Upgrade to PG13 failed for unrelated reasons, but a `VACUUM ..` brought down the avg CPU usage of our instance from ~70% to ~60%.

@aoldershaw yep that query is still the biggest consumer of resources, virtually no difference from the previous image (https://user-images.githubusercontent.com/736248/114151841-d7e2d300-991d-11eb-9db6-e50402861af5.png) Looking at a couple of examples from the query plan samples...

@aoldershaw sure thing! Ill leave it running for a few hours and update. @clarafu ``` id | name | status | scheduled | start_time | end_time | schema | private_plan...

Hmm, actually @aoldershaw that index doesnt seem to do much. ``` tablename | indexname | num_rows | table_size | index_size | unique | number_of_scans | tuples_read | tuples_fetched ---------------------------------------+-----------------------------------------------------------------+-------------+------------+------------+--------+-----------------+---------------+---------------- builds...

@aoldershaw Thanks! Applied it and `number_of_scans`, `tuples_read` and `tuples_fetched` are all incrementing for the update `deleteme` index now and `order_builds_by_rerun_of_or_id_idx`'s values are stagnant.. CPU usage down to 44% from ~57%,...

Hazzah, Now the big query is the second, first one is `UTILITY COMMAND`, unclear what that is but I think it's GCP SQL related.

@aoldershaw thanks a lot for helping :) Yep, Ill keep y'all update if something new creeps up.

@aoldershaw super 👍 I'll plan it in for next week.