perf(delete): sequential ascending-PK batch resolution for legacy layouts - #380
Merged
Conversation
…outs DeleteMultipleKeys on a legacy variable-length plaintext Columnar table resolved pk-literal batches with one B-tree search + row decode per target. For a strictly-ascending INTEGER-PK batch this is now one sequential decode pass that starts at the first target's position and early-exits once all targets matched. Strict gates keep results identical: PageBased/fixed-width/encrypted layouts, non-PK or non-ascending keys, duplicate keys, batches whose first-to-last target byte span exceeds 2 MB and physically unordered files (detected by a monotonicity pre-pass from offset 0) all fall back to the existing per-row path. Tombstone markers are skipped by their encoded slot span (|prefix|) so live rows behind a deleted row are never skipped. Regression: LegacyUnorderedLayout_AscendingPkBatchDelete_StaysCorrectAcrossReopen (covers the set-based scan-to-EOF fallback when the physical layout is unordered) plus the existing legacy prefix-delete test. Full suite 1766 tests, 0 failed. Fair-PK legacy DELETE stays within noise on this harness (path is gated to compact plaintext variable-length files); the fix removes a whole class of mis-skip risks for the next legacy wide-row milestone.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Samenvatting
Sequentiële ascending-PK batch-resolutie voor het legacy DELETE-pad (Fase B: legacy fast paths).
DeleteMultipleKeysop een legacy (variabele-lengte, plaintext, niet-fixed-width) Columnar-tabelresolved een strikt-oplopende INTEGER-PK literal-batch nu met één sequentiële decode-pass die
start op de positie van het eerste doel en vroeg stopt zodra alle doelen zijn gevonden — i.p.v.
één B-tree search + row-decode per doel.
Strikte gates (resultaat identiek aan de oude per-rij weg):
fallback; tijdens de scan wordt bij een disorder doorgegaan tot EOF met set-matching.
|prefix|), zodat live rijenáchter een verwijderde rij nooit worden overgeslagen (regressie die de suite vond en vaste).
Validatie
LegacyUnorderedLayout_AscendingPkBatchDelete_StaysCorrectAcrossReopen(geschudde fysieke volgorde → set-scan tot EOF; exacte keyset + reopen).
compacte plaintext variabele-lengte bestanden); dit is de correctheids-veilige fundering voor de
volgende legacy-wide-row stap.