Promotion lock at 100k files: stop re-stamping carried rows (13.9 s, 89.9% is the carry) #307
Labels
No labels
code-review
correctness
dos
performance
security
severity/high
severity/low
severity/medium
tech-debt
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Reference
h-dv/code-index#307
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during Phase 1 of the pluggable-languages work (lane R, 2026-09-26). This must be resolved before a language flips to a package, because every package extraction then goes through generation promotion.
State: at 100k files, generation promotion holds the write lock for about 13.94 s (
bench_promotion_lock, nightly). The existing record attributes 89.9% of that to "the carry": the UPDATE that re-stampsgeneration_idon every carried row, which cascades by trigger into symbols, refs and imports.Direction: do not re-stamp carried rows. For example, keep the active generation's id and move only the dirty rows. This is a schema and read-path redesign across the ~58 places that filter on the active generation.
Gates:
bench_promotion_lockbefore and after, run on a quiet machine.