Skip to content

Skip blanking a page that was never used - #77

Closed
martian56 wants to merge 1 commit into
mainfrom
skip-clear-retest
Closed

Skip blanking a page that was never used#77
martian56 wants to merge 1 commit into
mainfrom
skip-clear-retest

Conversation

@martian56

Copy link
Copy Markdown
Owner

Retest under the paired harness. This was measured once before it existed and the numbers were unusable: arm64 plus 10.9, 1cpu minus 17.0, x64-full minus 88.7 with write p99 at 115 ms, which is a degraded runner rather than a result.

Rolling onto a new packing page blanks it through a full commit round trip, and that happens while the open page lock is held, so every other writer waits on it. Only a page taken off the free pool needs blanking. A page that has never been used is past the end of the file and already reads as empty, so the round trip is pure cost.

Now that both builds run on the same runner this can be judged.

Rolling to a new packing page blanked it through a full commit round
trip while the open page lock was held, stalling every other writer.
Only a page off the free pool needs that: a fresh one is past the end
of the file and already reads as empty.
@coderabbitai

coderabbitai Bot commented Jul 25, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@martian56, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f4cad7a8-6dda-4e1e-9b0f-5291fbce3663

📥 Commits

Reviewing files that changed from the base of the PR and between b70d500 and 542c84f.

📒 Files selected for processing (3)
  • mvcc/src/database.rs
  • storage/src/group_commit.rs
  • storage/src/store.rs
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch skip-clear-retest

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown
Contributor

Bench report

✅ Best improvement: windows-x64-full mixed at +34.4%. Nothing regressed beyond noise.

Baseline: main @ same runn. Cells read baseline → this PR. Verdicts need more than ±15% to leave the noise band.

linux-arm64-full

workload ops/s Δ ops/s read p99 ms write p99 ms write p99.9 ms
reads 32956 → 32586 ⚪ -1.1% 0.21 → 0.22 - -
mixed 14889 → 13681 ⚪ -8.1% 0.43 → 0.43 13.06 → 19.06 33.01 → 34.25
writes 6225 → 6038 ⚪ -3.0% - 6.03 → 6.22 30.08 → 29.52

linux-x64-1cpu-1gb

workload ops/s Δ ops/s read p99 ms write p99 ms write p99.9 ms
reads 22618 new 0.23 - -
mixed 5377 new 0.38 44.83 202.89
writes 2483 new - 20.43 169.99

linux-x64-2cpu-2gb

workload ops/s Δ ops/s read p99 ms write p99 ms write p99.9 ms
reads 15003 new 0.42 - -
mixed 10263 new 0.57 4.93 18.18
writes 5236 new - 2.38 11.83

linux-x64-full

workload ops/s Δ ops/s read p99 ms write p99 ms write p99.9 ms
reads 24760 → 24959 ⚪ +0.8% 0.28 → 0.27 - -
mixed 14371 → 14388 ⚪ +0.1% 0.43 → 0.38 4.21 → 4.13 17.91 → 18.59
writes 6133 → 6287 ⚪ +2.5% - 2.13 → 2.11 11.84 → 11.87

windows-x64-full

workload ops/s Δ ops/s read p99 ms write p99 ms write p99.9 ms
reads 22470 → 21299 ⚪ -5.2% 0.37 → 0.50 - -
mixed 5413 → 7274 🟢 +34.4% 0.35 → 0.34 30.61 → 22.35 41.27 → 34.55
writes 826 → 755 ⚪ -8.6% - 16.29 → 16.41 27.89 → 33.50

Field reference

All engines in identical containers, same driver, measured 2026-07-24 @ ba0ec39. A different harness than the tables above, so read this as standing, not as this PR's delta.

linux-arm64-full

engine reads mixed writes
quantadb 17978 12420 (27ms wp99) 6449 (19ms wp99)
postgres18 15227 14723 (2ms wp99) 9923 (1ms wp99)
mariadb114 4221 4437 (8ms wp99) 6666 (3ms wp99)
mysql84 4258 4394 (9ms wp99) 4274 (4ms wp99)

linux-x64-1cpu-1gb

engine reads mixed writes
quantadb 19419 10854 (29ms wp99) 5170 (39ms wp99)
postgres18 10196 8580 (43ms wp99) 5912 (46ms wp99)
mariadb114 3455 3732 (4ms wp99) 5626 (8ms wp99)
mysql84 3497 3628 (4ms wp99) 3259 (36ms wp99)

linux-x64-2cpu-2gb

engine reads mixed writes
quantadb 22528 16774 (5ms wp99) 8374 (4ms wp99)
postgres18 17060 17006 (2ms wp99) 11404 (1ms wp99)
mariadb114 3735 4006 (3ms wp99) 6741 (3ms wp99)
mysql84 3804 3845 (4ms wp99) 4847 (3ms wp99)

linux-x64-full

engine reads mixed writes
quantadb 18144 15075 (6ms wp99) 8025 (5ms wp99)
postgres18 15402 15154 (2ms wp99) 10872 (1ms wp99)
mariadb114 3437 3699 (4ms wp99) 6138 (3ms wp99)
mysql84 3490 3615 (4ms wp99) 3996 (5ms wp99)

Shared CI runners: treat single-profile swings as suggestive, agreement across profiles as real.

@martian56

Copy link
Copy Markdown
Owner Author

Measured against a same runner baseline and rejected as neutral.

  • linux-x64-full: plus 2.5 percent
  • linux-arm64-full: minus 3.0 percent
  • windows-x64-full: minus 8.6 percent
  • docker profiles had no paired baseline this run

All inside the band. The reasoning was sound but the cost is not there: a rollover happens roughly once per fifty records, so even a full commit round trip under the lock amortises to almost nothing per write.

Worth contrasting with the first attempt, which reported plus 10.9, minus 17.0 and minus 88.7 on three profiles for this same change. That spread was the harness, not the code, and it is the clearest example yet of why the paired baseline was worth building.

@martian56 martian56 closed this Jul 25, 2026
@martian56
martian56 deleted the skip-clear-retest branch July 25, 2026 10:09
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