Skip to content
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

[release/6.0] Fix to #27072 - Suboptimal SQL generation for query with optional navigation, its collection navigation and lateral join #27302

Merged
merged 1 commit into from
Feb 2, 2022

Conversation

maumar
Copy link
Contributor

@maumar maumar commented Jan 27, 2022

Fixes #27072

Description

When expanding collection navigation we added a check to filter out rows for which parent value is null and only afterwards match inner and outer keys. This could happen when chaining collection navigation after optional reference. Problem was that during translation we try to convert the collection subquery to a join and if that succeeds we don't need the null check anymore - joins key comparison doesn't match nulls. However, we also remove the null check when we are not able to convert to JOIN and use APPLY instead.

Fix is to save the original predicate before we try to extract the join predicate and then for APPLY case re-apply the original predicate and only use the extracted join predicate for the JOIN case.

Customer impact

Customers running query with affected scenarios can receive incorrect results.

How found

Customer reported on 6.0

Regression

No.

Testing

Added test for user reported scenario. Several existing tests also cover the code path (and had the generated sql changed as a result), but they didn't have specific data to manifest the data corruption.

Risk

Low risk. We are re-applying the original predicate without doing any additional processing on it. Also added quirk to revert to previous behavior.

…igation, its collection navigation and lateral join

When expanding collection navigation we added a check to filter out rows for which parent value is null and only afterwards match inner and outer keys. This could happen when chaining collection navigation after optional reference. Problem was that during translation we try to convert the collection subquery to a join and if that succeeds we don't need the null check anymore - joins key comparison doesn't match nulls. However, we also remove the null check when we are not able to convert to JOIN and use APPLY instead.

Fix is to save the original predicate before we try to extract the join predicate and then for APPLY case re-apply the original predicate and only use the extracted join predicate for the JOIN case.

Fixes #27072
@leecow leecow added this to the 6.0.3 milestone Feb 1, 2022
@wtgodbe wtgodbe merged commit 1a6ffb7 into release/6.0 Feb 2, 2022
@wtgodbe wtgodbe deleted the fix27072_60 branch February 2, 2022 17:37
@ajcvickers ajcvickers removed this from the 6.0.3 milestone Feb 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants