Fix/batch inprogress mutations

[ruslanen]

Batch system.mutations lookup to avoid O(N²) on installations with many tables

Problem

During create, in-progress mutations are fetched once per table via
GetInProgressMutations(ctx, database, table):

SELECT mutation_id, command FROM system.mutations WHERE is_done=0 AND database=? AND table=?

system.mutations is a virtual table: every query against it enumerates all tables on the
server, so the per-table WHERE database/table filter does not bound the work that ClickHouse
actually does. With N tables in the backup we issue N such queries, and each one costs
~O(total tables) → overall O(N²).

On installations with many tables this single query family dominates create wall-clock. Observed
on a real cluster: ~240 ms per call across tens of thousands of tables, collapsing create
throughput from ~250 tables/s to ~26 tables/s.

Fix

Fetch the whole in-progress mutation set once per backup with a single scan:

SELECT database, table, mutation_id, command FROM system.mutations WHERE is_done=0

GetInProgressMutationsBatch returns a map["database.table"][]MutationMetadata; the per-table
code path now does an in-memory map lookup instead of a query. Query count drops from N → 1.

Behavior unchanged

• Same WHERE is_done=0 filter as before.
• Same per-table Mutations written into TableMetadata.
• The batch query runs only when the per-table query would have run before (BackupMutations
  enabled and not schema/rbac/configs/named-collections-only).

Tests

Added TestGroupMutationsByTable (+ empty-input case) covering the pure groupMutationsByTable
helper: rows from one server-wide scan are bucketed to the correct database.table with no
cross-table leakage and in stable order.

Impact (measured)

55k-table / 93.6 GiB local backup: create ~35 min → ~230 s.

Files

• pkg/clickhouse/clickhouse.go — GetInProgressMutationsBatch, inProgressMutationRow, groupMutationsByTable
• pkg/backup/create.go — single batch call, per-table map lookup
• pkg/clickhouse/clickhouse_test.go — unit tests

[Slach]

look to metadata.TableTitle

r.Database + "." + r.Table

this is bad key

you not cover lot of corner cases

[Slach]

thanks for contribution

but, actually if you have more than 1000 mutations, this is means something wrong with your achitecture

scan in-memory system.mutations for each table, is not so dangerous

[Slach]

ok. i figure out about O(N^2) for system.mutation, you are right let me fix TableTitle approach