-
Notifications
You must be signed in to change notification settings - Fork 4.1k
opt: inline constant values for foreign key checks #63882
Copy link
Copy link
Open
Labels
A-multiregionRelated to multi-regionRelated to multi-regionC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-sql-queriesSQL Queries TeamSQL Queries Team
Metadata
Metadata
Assignees
Labels
A-multiregionRelated to multi-regionRelated to multi-regionC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)C-performancePerf of queries or internals. Solution not expected to change functional behavior.Perf of queries or internals. Solution not expected to change functional behavior.T-sql-queriesSQL Queries TeamSQL Queries Team
Type
Projects
Status
Backlog
As described in #63735, we cannot compute constant values for computed columns when planning foreign key checks, since the foreign key checks scan the mutation buffer rather than using the values directly from an INSERT, UPDATE, or UPSERT statement. For example, consider the following (simplified) schema:
The referenced tables
customeranddistricthave a computed columncrdb_regionwith the same definition. Running a query like:should allow the foreign key checks to determine that
crdb_regionis 'us-east1' and avoid communication with remote regions, but this is currently not possible. This is currently somewhat mitigated by locality optimized anti joins, but ideally we wouldn't need to rely on any sort of locality optimized search whencrdb_regionis computed.Jira issue: CRDB-6809