-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql: foreign key checks should only scan the primary column family of a row #30852
Comments
@nvanbenschoten can you double check the issue description? Is this optimization also valid if the FK references a non-primary (unique) index? |
If we supported multiple column families in secondary indexes then it would be. I forget if we do or if secondary indexes are encoded in such a way that we could in the future. The only requirement is that we need to verify that the row exists, and that can be performed looking only at the primary column family of whatever index we need to look at. Scanning any other column families in the destination row is a waste. |
Ping @RaduBerinde. Would be good to keep this in mind when doing FK work. |
@jordanlewis this will come down to optimizing the scans performed by lookup semi/anti joins. |
Yep - we'll make sure this gets done. Thanks! |
In conjunction with planning foreign key checks via the optimizer, this work was materially finished by @rohany in #38301. Assigning to @RaduBerinde to close once opt-driven fks are in. |
I just confirmed that this is still a blocker for #30624. This is true with and without With a tpcc dataset initialized from that PR with 1 warehouse:
|
I tried to reproduce locally with two simple tables. A few things I found:
Can you get the |
Even with those two changes, it still hangs. Here's the
If I drop the FK, things do work, so that's where the contention is coming from. |
If that is your explain, the new FK path is not on. Make sure you restarted the session if you changed the cluster setting, or use the session variable ( |
Oh yes, you're right. The FK check does not conflict with the UPDATE when using the new FK path.
|
This change improves the legacy FK path to only scan the primary column family. The new path already does this (as long as the best plan is a lookup join). Adding a test for both paths. Fixes cockroachdb#30852. Release note: None
This change improves the legacy FK path to only scan the primary column family. The new path already does this (as long as the best plan is a lookup join). Adding a test for both paths. Fixes cockroachdb#30852. Release note: None
42572: sql: scan only primary column for FK checks r=RaduBerinde a=RaduBerinde This change improves the legacy FK path to only scan the primary column family. The new path already does this (as long as the best plan is a lookup join). Adding a test for both paths. Fixes #30852. Release note: None 42596: sql: remove local ordinality r=jordanlewis a=jordanlewis Now that it's got a distributed version, we can delete the local implementation. Release note: None Co-authored-by: Radu Berinde <[email protected]> Co-authored-by: Jordan Lewis <[email protected]>
We currently scan all column families in the destination row when performing a foreign key check. We should limit this to the primary column family, which we know will never be missing as long as the row exists.
This has implications on transaction contention. For instance, see #30624.
cc. @knz for triage.
The text was updated successfully, but these errors were encountered: