Remove the CI partitioning routing analyzer

Marius Bobinrequested to merge
refactor/remove-partitioning-routing-analyzer into master

What does this MR do and why?

This MR removes Gitlab::Database::QueryAnalyzers::Ci::PartitioningRoutingAnalyzer and its ops feature flag ci_partitioning_analyze_queries. The analyzer can no longer detect anything, but it still runs on every SQL statement in specs.

Why the analyzer is no longer needed

The analyzer raises RoutingTableNotUsedError when a query names one of these tables directly: ci_builds, ci_builds_metadata, ci_job_artifacts, ci_pipeline_variables, ci_pipelines, ci_stages. It helped move code to the partitioned p_ci_* tables.

These tables are no longer in the public schema. Each one has an entry in db/docs/deleted_tables/, and they moved into the gitlab_partitions_dynamic schema. GitLab keeps partition schemas out of the search path. So a query that names one of these tables without a schema already fails in PostgreSQL. A schema-qualified name such as gitlab_partitions_dynamic.ci_builds never matches the analyzer's table list.

The feature flag is default-off, but specs enable all feature flags, so the analyzer checks every SQL statement in specs.

The MR also removes:

  • The :suppress_partitioning_routing_analyzer spec metadata tag and its support file. No spec uses the tag.
  • The analyzer suppression in Gitlab::Database::TablesTruncate.
  • The related .rubocop_todo entries.

After this MR is deployed, delete any stored flag state on GitLab.com with /chatops run feature delete ci_partitioning_analyze_queries.

References

Screenshots or screen recordings

Not applicable. This MR does not change the UI.

How to set up and validate locally

There are no manual steps.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports