Repository navigation
perf: cut the fixed per-change cost of a watched batch reconcile - #1564
Merged
Merged
Conversation
Read a table's key candidates once per schema version, read its columns through a cached statement, skip the range refit when every change is an in-place update, and fit the range from the rowids the reconcile placed rather than a min/max query.
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
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.
Refs #1562
Root cause
A real fixed per-change overhead, plus a noisy 15-pair measurement. It is not a recent regression: commits back to 2026-10-14 fail the same bar on this host.
main, 300-pair raw runs: native median 388us, dirsql 435-439us, ratio 1.12-1.14 across 3 runs. That is about 48us of fixed cost per change.main, in us after the write: hook spawn 36,catEOF 225, child reaped 247, reconcile done 313, consumer has the event 337.row_keyalone took ~17us, because it ran three pragma queries on every rerun.min/maxquery, INSERT) took ~14us.Change (
packages/rust/src/db.rs)PRAGMA schema_version, so any schema change invalidates them.get_table_columnsuses a cachedpragma_table_info(?1)select.min/maxquery.After the change, reconcile is ~18-21us live (
row_keyis ~0.5us).Measurements (same host, interleaved runs, bar = 1.1x, lower is better)
The test is still not reliably green on a loaded host: the same binary ranges 0.95-1.34 from run to run. The remaining ~20-25us gap is structural:
cat's own exit costThings tried with no measurable gain, reverted:
prepare_cachedfor the transaction statements, translating watcher events on the reading thread, reaping the child on the stderr thread (worse), and spinning ontry_waitafter EOF.Changelog / Migrations
<root>/<pkg>/changelog.d/for each changed package (or:skip-changelogtrailer on a commit with reason)<root>/<pkg>/migrations.d/for each changed package (every subsection but Summary_None._when nothing breaks)E2E Verification
cargo test --lib: 1299 passed)packages/python/e2e-attestations/<branch>.jsonreceipt written ifpackages/pythonchanged (just e2e-attest-python)packages/ts/e2e-attestations/<branch>.jsonreceipt written ifpackages/tschanged (just e2e-attest-ts)testing-conventions e2e attest 'uv run python -m pytest tests/e2e/on_file_query_test.py tests/e2e/query_contract_test.py tests/e2e/declared_table_name_test.py tests/e2e/fanout_test.py tests/e2e/use_case_dossier_test.py tests/e2e/use_case_join_test.py tests/e2e/use_case_notebook_test.py tests/e2e/use_case_transcripts_test.py tests/e2e/watch_speed_test.py -q'just e2e-attest-tswatch_speed_testpassed on that run, but it passes only ~70% of runs on this host (see above).