Problem
Merges with disjoint source/target branch pairs queue within one graph, limiting throughput even when their changes do not conflict.
Reproduced on 0.10.0 with real MinIO behind a proxy adding 17 ms per physical request:
| Concurrent merges |
Live non-main branches |
Matched single control |
Completion times from batch start |
| 4 |
10 |
3.806 s |
3.938, 7.704, 11.448, 15.201 s |
| 8 |
18 |
4.374 s |
4.663, 8.920, 13.224, 17.527, 21.772, 25.971, 30.159, 34.433 s |
Each pair had disjoint row edits. Every merge succeeded and both intended values were verified. These are one batch per condition, not tail-latency estimates. A four-merge diagnostic source build showed waiting/preparation growing from 1.402 to 13.874 s while classification remained about 1.24 s.
branch_merge_impl acquires the shared __schema_apply__ exclusive queue key for the operation. It also holds merge_exclusive while swapping and restoring the handle's active coordinator. The first gate already forces serialization. The measurements do not independently apportion wait time between the two guards.
Proposed change
Design branch-specific merge execution context so an operation does not temporarily repoint shared mutable coordinator state. Then define schema/lifetime exclusion and publication interleavings that admit independent target merges safely.
Simply dropping either guard is not sufficient: branch incarnations, schema authority, recovery barriers, captured source state and target publication CAS must remain coherent. RFC #638 retains the current guards and improves preparation within one admitted merge; it does not solve this queue.
Acceptance criteria
- Independent pairs overlap useful work within explicit CPU/I/O/memory admission limits.
- Same-target merges retain deterministic conflict/serialization behavior; same-source and shared-table cases are covered.
- Test schema apply, fork/delete/recreate, source advance, failure/recovery and cancellation at the relevant boundaries.
- Measure throughput, queue wait, per-operation latency and aggregate RSS under 1/2/4/8 concurrent merges, verifying final graph contents and receipts.
Problem
Merges with disjoint source/target branch pairs queue within one graph, limiting throughput even when their changes do not conflict.
Reproduced on 0.10.0 with real MinIO behind a proxy adding 17 ms per physical request:
Each pair had disjoint row edits. Every merge succeeded and both intended values were verified. These are one batch per condition, not tail-latency estimates. A four-merge diagnostic source build showed waiting/preparation growing from 1.402 to 13.874 s while classification remained about 1.24 s.
branch_merge_implacquires the shared__schema_apply__exclusive queue key for the operation. It also holdsmerge_exclusivewhile swapping and restoring the handle's active coordinator. The first gate already forces serialization. The measurements do not independently apportion wait time between the two guards.Proposed change
Design branch-specific merge execution context so an operation does not temporarily repoint shared mutable coordinator state. Then define schema/lifetime exclusion and publication interleavings that admit independent target merges safely.
Simply dropping either guard is not sufficient: branch incarnations, schema authority, recovery barriers, captured source state and target publication CAS must remain coherent. RFC #638 retains the current guards and improves preparation within one admitted merge; it does not solve this queue.
Acceptance criteria