Skip blanking a page that was never used - #77
Conversation
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.
|
Warning Review limit reached
Next review available in: 19 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
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
linux-x64-1cpu-1gb
linux-x64-2cpu-2gb
linux-x64-full
windows-x64-full
Field referenceAll 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
linux-x64-1cpu-1gb
linux-x64-2cpu-2gb
linux-x64-full
Shared CI runners: treat single-profile swings as suggestive, agreement across profiles as real. |
|
Measured against a same runner baseline and rejected as neutral.
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. |
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.