Skip to content

perf(delete): batch commit-time tombstone marker writes per storage page (C5) - #377

Merged
MPCoreDeveloper merged 1 commit into
masterfrom
perf/batch-commit-markers
Sep 4, 2026
Merged

perf(delete): batch commit-time tombstone marker writes per storage page (C5)#377
MPCoreDeveloper merged 1 commit into
masterfrom
perf/batch-commit-markers

Conversation

@MPCoreDeveloper

Copy link
Copy Markdown
Owner

Samenvatting

Commit-time tombstone-marker writes worden per storage-page gebundeld (C5).

ApplyBufferedTombstonesTombstoneRecords deed na #373 (whole-file range-read) nog steeds één 4-byte pwrite per verwijderde rij; dat domineerde de DELETE-commit-fase op dichte batches. Nu:

  1. Pass 1: alle geldige negatieve-prefix markers worden eerst in het in-memory whole-file snapshot gepatcht. Omdat records niet page-gealigned zijn en een marker de 4096-grens kan kruisen, moet patchen op de aaneengesloten buffer gebeuren (niet op per-page kopieën — dat gaf eerst een ArgumentOutOfRangeException op straddlers, gevonden door FixedWidthBulkDeleteTests).
  2. Pass 2: elke geraakte storage-page wordt één keer weggeschreven uit het gepatchte buffer. Een geflushte page verschilt alleen in de omgedraaide marker-woorden van de on-disk bytes → byte-voor-byte equivalent aan de oude individuele marker writes.

Veiligheid: draait onder hetzelfde lock als voorheen (appendLock op het commit-pad / table-write-lock op het duurzame pad); elke page maximaal één write vanuit de snapshot → rollback kan nooit een half toegepaste marker zien.

Metingen (fair-PK harness --pk, zelfde machine als master, 2 runs elk)

Variant master deze branch
legacy DELETE 10K ~68-72K ops/s ~80-81K ops/s (+16%)
fixed-width DELETE 10K ~97-111K ops/s ~136-147K ops/s (+45%)

DELETE-gap vs SQLite op fixed-width daalt daarmee van ~3,0-3,3x naar ~2,4x.

Validatie

  • Full suite: 1762 tests, 0 failed (Release).
  • De nieuwe code-path wordt afgedekt door bestaande regressietests (commit-time tombstones overleven reopen zonder expliciete flush; fixed-width/legacy bulk-deletes met 1000+ rijen op tabellen ≤ 32 MB).

…age (C5)

ApplyBufferedTombstones -> TombstoneRecords still issued one 4-byte pwrite per
deleted row even after #373 batched the per-marker length reads. The DELETE
commit phase now patches every negative-prefix marker into the in-memory
whole-file snapshot first (markers may straddle page boundaries because records
are not page-aligned, so patching must happen on the contiguous buffer, not on
per-page copies) and then flushes each touched storage page exactly once.
A flushed page differs from the on-disk bytes only in its flipped marker words,
so the full-page write is byte-for-byte equivalent to the individual marker
writes it replaces. Runs under the same lock as before (appendLock on the
commit path / table write lock on the durable path), so rollback semantics are
unchanged.

Fair-PK harness (--pk, same machine as master, 2 runs each):
  legacy DELETE   ~70K  -> ~81K ops/s  (+16%)
  fixed-width DEL ~97K  -> ~141K ops/s (+45%); DELETE gap vs SQLite -> ~2.4x

Full suite: 1762 tests, 0 failed.
@sonarqubecloud

sonarqubecloud Bot commented Sep 4, 2026

Copy link
Copy Markdown

@MPCoreDeveloper
MPCoreDeveloper merged commit 8985a08 into master Sep 4, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant