Skip to content

Finalize new index and update schema

What does this MR do and why?

This MR adds a concurrent index build in a post-migration, that should execute immediately as a no-op since it'll be run after !87325 (merged), which will have built the index over the weekend.

We'll verify that the planner has picked up the new index and started using for it querying artifacts with an unknown locked status, merge this finalization, and then look to remove the index no longer being used.

The rationale and index design is laid out in our tracking issue.

Output of Migrations

From the db:check-migrations job.

$ scripts/db_tasks db:migrate
== 20220511212620 AddIndexOnExpirableUnknownArtifactsForRemoval: migrating ====
-- transaction_open?()
   -> 0.0000s
-- index_exists?("ci_job_artifacts", [:expire_at, :job_id], {:name=>"tmp_index_ci_job_artifacts_on_expire_at_where_locked_unknown", :where=>"locked = 2 AND expire_at IS NOT NULL", :algorithm=>:concurrently})
   -> 0.0103s
-- execute("SET statement_timeout TO 0")
   -> 0.0006s
-- add_index("ci_job_artifacts", [:expire_at, :job_id], {:name=>"tmp_index_ci_job_artifacts_on_expire_at_where_locked_unknown", :where=>"locked = 2 AND expire_at IS NOT NULL", :algorithm=>:concurrently})
   -> 0.0020s
-- execute("RESET statement_timeout")
   -> 0.0005s
== 20220511212620 AddIndexOnExpirableUnknownArtifactsForRemoval: migrated (0.0201s) 

Index verification in production

TODO fill in after async build is complete

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by drew stachon

Merge request reports