You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The step comes from #540 (backport of #476): before it, the usize::MAX close-time drop still saved the .graph, so this fixture replayed 0 WAL entries. It now replays all 100k, which is the work the benchmark is meant to measure. The latency has been flat at ~3 s since the step. Commits between the two alert runs (72d847e..d604cc4) are CI, a unit test and a fuzz corpus only; 1k and 10k are unchanged.
#568 (merged today) limits the comparison to the last 30 runs, so a lasting step alerts for a few more runs and then becomes the baseline. Further re-fires of this benchmark at ~3 s can be closed the same way.
Activity
adityamukho commentedon Oct 13, 2026
Not a code regression. This is the same step as #561, re-alerting.
open/wal_replay/100kon main (Bencher, ubuntu-latest):The step comes from #540 (backport of #476): before it, the
usize::MAXclose-time drop still saved the.graph, so this fixture replayed 0 WAL entries. It now replays all 100k, which is the work the benchmark is meant to measure. The latency has been flat at ~3 s since the step. Commits between the two alert runs (72d847e..d604cc4) are CI, a unit test and a fuzz corpus only; 1k and 10k are unchanged.#568 (merged today) limits the comparison to the last 30 runs, so a lasting step alerts for a few more runs and then becomes the baseline. Further re-fires of this benchmark at ~3 s can be closed the same way.
🤖 Generated with Claude Code