Skip to content

Draft: Drop indexes and FKs from ci_build_trace_sections

Andreas Brandl requested to merge ab/drop-trace-section into master

What does this MR do and why?

We intend to drop and. This MR drops indexes and FKs to other tables on both tables.

Why not drop now? I'd like to drop those indexes right away as they are also known to be large and bloated on .com. We also remove FKs to projects, so the table is completely detached from the rest.

Dropping the table needs another round of approvals, so I anticipate this still takes a while before we can finally drop data.

GitLab.com usage

The table isn't being used anymore, although there are occasional index reads (presumably from monitoring?):

https://thanos-query.ops.gitlab.net/graph?g0.expr=sum(rate(pg_stat_user_tables_seq_tup_read%7Benv%3D%22gprd%22%2C%20relname%20%3D~%20%22dep_ci_build_trace_sections%7Cdep_ci_build_trace_section_names%22%7D%5B5m%5D))%20by%20(relname)&g0.tab=0&g0.stacked=0&g0.range_input=1y&g0.max_source_resolution=0s&g0.deduplicate=1&g0.partial_response=0&g0.store_matches=%5B%5D&g1.expr=sum(rate(pg_stat_user_indexes_idx_tup_read%7Benv%3D%22gprd%22%2C%20relname%20%3D~%20%22dep_ci_build_trace_sections%7Cdep_ci_build_trace_section_names%22%7D%5B5m%5D))%20by%20(relname%2C%20fqdn)&g1.tab=0&g1.stacked=0&g1.range_input=30d&g1.max_source_resolution=0s&g1.deduplicate=1&g1.partial_response=0&g1.store_matches=%5B%5D

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 Andreas Brandl

Merge request reports