{{ message }}
Repository navigation
Scope merge direction fact counts to each entity's knowledge base - #1078
Merged
Merged
Conversation
Signed-off-by: Floating-Y <118035379+Floating-Y@users.noreply.github.com>
WaylandYang
approved these changes
Oct 4, 2026
WaylandYang
left a comment
Contributor
There was a problem hiding this comment.
Thanks @Floating-Y. The two counts in merge_direction were the ones #1072 did not reach, since they take the entity by id and have no base in hand. Reading the base by primary key first is the right way to give both sides of the OR a seek on the (kb_id, …) indexes, and the regression covers what the direction depends on: live facts only, a self-reference counted once, the smaller id on a tie. Landing it.
Merged
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.

Why
Follow-up to #1072. The two live-fact counts in
resolution::merge_directionstill omitkb_id. The existing subject/object indexes lead withkb_id, so choosing a merge direction can scan index entries from other knowledge bases.What changes
kb_idby primary key. Preserve the function signature and two-query execution flow.Only the two queries and their regression coverage change. No new index, migration, or dependency.
How it was checked
PostgreSQL 16.15 in a dedicated test container, with session-local copies of the migrated tables and indexes: 4 knowledge bases, 20,000 entities, and 240,000 facts.
EXPLAIN (ANALYZE, BUFFERS)used the exact old and final SQL.The final plan has
(kb_id = $0 AND subject_id = $1)and(kb_id = $0 AND object_id = $1)index conditions. A forced generic prepared plan also uses both composite keys and 23 buffer accesses. These synthetic-fixture measurements do not imply a stable elapsed-time speedup or production throughput result.Passed locally:
cargo fmt --all --checkcargo clippy --workspace --all-targets -- -D warningscargo test --workspace --no-fail-fast: 1,427 passed, 0 failed, 6 ignored; includes all 298 store integration tests.cargo test --locked -p utopia-store --test store merge_direction_counts_live_facts_in_each_base: passed separately.pnpm install --frozen-lockfileandpnpm buildinweb.git diff --check.Database tests used
UTOPIA_DATABASE_URLpointing to the dedicated container andUTOPIA_TEST_REQUIRE_DB=1. On Windows, the final full run used an explicit127.0.0.1database host andNO_PROXY=127.0.0.1,localhost,::1. No business database was used.The six explicitly ignored live-service and isolated delivery/crash tests were not forced to run. Optional live MySQL/Trino/WebDAV services and opt-in benchmarks were not configured.
Before review
git commit -s)cargo fmt --all --check,cargo clippy --workspace --all-targets -- -D warningsandcargo test --workspacepasscrates/utopia-store/was tested withUTOPIA_DATABASE_URLset (those tests skip without it)