-
Notifications
You must be signed in to change notification settings - Fork 102
refactor joins to use direct implementation or each type rather than composition of inner+anti joins #571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 525621b The changes in this PR will be included in the next version bump. This PR includes changesets to release 13 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
Size Change: -16 B (-0.02%) Total Size: 76.9 kB
ℹ️ View Unchanged
|
Size Change: 0 B Total Size: 1.46 kB ℹ️ View Unchanged
|
if (multiplicity !== 0) { | ||
results.add( | ||
[key, [value, null]], | ||
retract ? -multiplicity : +multiplicity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get the retract logic. If the key used to have multiplicity 0, then retract
is true
so we will add the new change to the index but with its negated multiplicity, why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've improved the comments and naming to try and explain this better, it's not really retraction, it that we are transitioning from not having any matches, to having matches, and so we need to send a retraction of the old row, with its old multiplicity so that the new rows can be sent.
const after = before + deltaMass | ||
|
||
// Skip if presence doesn't flip (0->0, >0->different>0) | ||
if ((before === 0) === (after === 0)) continue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the presence doesn't flip, don't we need to update the indexes/mass index ?
Say, that before
is 5
and the new delta has multiplicity -3
. Then after
is 2
. So it is still visible and this won't update the index so in the index the key will still have multiplicity 5
. Next time, if it receives a multiplicity of -3
the key will still not flip (even though it should at this point!) because it thinks the multiplicity is 5. This looks wrong to me?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating the multiplicity in the indexes happens regardless of this section of code, at the end of run()
.
d7d8b48
to
7c52d67
Compare
7c52d67
to
9999958
Compare
This removes all the additional state that was needed for each of the composed joins, and the need for the consolidate step. Delivers a father 50% speedup over the index refactor PR #549 this is stacked on.