-
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
roachtest.tlp failed: incorrect cardinality of EXCEPT produces incorrect results #89101
Comments
Hi @rytaft, please add a C-ategory label to your issue. Check out the label system docs. While you're here, please consider adding an A- label to help keep our repository tidy. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan. |
Here is a reproduction:
This issue exists on 21.2 and 22.1, so this is not a release blocker. |
A simpler reproduction with the joins removed:
|
This query is incorrect:
It produces 1 row when it should produce 0 rows:
It appears to be a bug in the optimizer, since the plan produced is a simple full table scan:
|
I've found the problem. The cardinality property of
We incorrectly assume that the EXCEPT produces at least one row, when in fact it can produce 0 rows. In other words,
should be:
|
89042: kvserver: decrease verbosity of replicate queue trace logging r=AlexTalks a=AlexTalks While logging of traces on replicate queue errors was recently added, logging these traces at the `WARNING` level appears to be too high, causing noisy logs. This change decreases the verbosity of these logs to the `INFO` level. Release note: None 89108: opt: fix min cardinality calculation of EXCEPT r=rytaft a=rytaft Prior to this commit, we assumed that the minimum cardinality of `EXCEPT` could never be lower than the minimum cardinality of the left side minus the maximum cardinality of the right side. However, this assumption is only true for `EXCEPT ALL`, not `EXCEPT`. For example, `VALUES (1), (1) EXCEPT VALUES (1)` produces 0 rows, even though the left side produces more rows than the right. Because of this invalid assumption, the optimizer could make some invalid transformations, resulting in incorrect results. Fixes #89101 Release note (bug fix): Fixed a bug that has existed since v2.1.0 where queries containing a subquery with `EXCEPT` could produce incorrect results. This could happen if the optimizer could guarantee that the left side of the `EXCEPT` always returned more rows than the right side. In this case, the optimizer made a faulty assupmtion that the `EXCEPT` subquery always returned at least one row, which could cause the optimizer to perform an invalid transformation, possibly causing the full query to return incorrect results. 89112: sql: correctly reset the planner in the copy shim r=yuzefovich a=yuzefovich Previously, we forgot to update the txn of the eval context of the planner. Release note: None Co-authored-by: Alex Sarkesian <[email protected]> Co-authored-by: Rebecca Taft <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]>
Prior to this commit, we assumed that the minimum cardinality of EXCEPT could never be lower than the minimum cardinality of the left side minus the maximum cardinality of the right side. However, this assumption is only true for EXCEPT ALL, not EXCEPT. For example, VALUES (1), (1) EXCEPT VALUES (1) produces 0 rows, even though the left side produces more rows than the right. Because of this invalid assumption, the optimizer could make some invalid transformations, resulting in incorrect results. Fixes #89101 Release note (bug fix): Fixed a bug that has existed since v2.1.0 where queries containing a subquery with EXCEPT could produce incorrect results. This could happen if the optimizer could guarantee that the left side of the EXCEPT always returned more rows than the right side. In this case, the optimizer made a faulty assupmtion that the EXCEPT subquery always returned at least one row, which could cause the optimizer to perform an invalid transformation, possibly causing the full query to return incorrect results.
Prior to this commit, we assumed that the minimum cardinality of EXCEPT could never be lower than the minimum cardinality of the left side minus the maximum cardinality of the right side. However, this assumption is only true for EXCEPT ALL, not EXCEPT. For example, VALUES (1), (1) EXCEPT VALUES (1) produces 0 rows, even though the left side produces more rows than the right. Because of this invalid assumption, the optimizer could make some invalid transformations, resulting in incorrect results. Fixes #89101 Release note (bug fix): Fixed a bug that has existed since v2.1.0 where queries containing a subquery with EXCEPT could produce incorrect results. This could happen if the optimizer could guarantee that the left side of the EXCEPT always returned more rows than the right side. In this case, the optimizer made a faulty assupmtion that the EXCEPT subquery always returned at least one row, which could cause the optimizer to perform an invalid transformation, possibly causing the full query to return incorrect results.
Prior to this commit, we assumed that the minimum cardinality of EXCEPT could never be lower than the minimum cardinality of the left side minus the maximum cardinality of the right side. However, this assumption is only true for EXCEPT ALL, not EXCEPT. For example, VALUES (1), (1) EXCEPT VALUES (1) produces 0 rows, even though the left side produces more rows than the right. Because of this invalid assumption, the optimizer could make some invalid transformations, resulting in incorrect results. Fixes #89101 Release note (bug fix): Fixed a bug that has existed since v2.1.0 where queries containing a subquery with EXCEPT could produce incorrect results. This could happen if the optimizer could guarantee that the left side of the EXCEPT always returned more rows than the right side. In this case, the optimizer made a faulty assupmtion that the EXCEPT subquery always returned at least one row, which could cause the optimizer to perform an invalid transformation, possibly causing the full query to return incorrect results.
Prior to this commit, we assumed that the minimum cardinality of EXCEPT could never be lower than the minimum cardinality of the left side minus the maximum cardinality of the right side. However, this assumption is only true for EXCEPT ALL, not EXCEPT. For example, VALUES (1), (1) EXCEPT VALUES (1) produces 0 rows, even though the left side produces more rows than the right. Because of this invalid assumption, the optimizer could make some invalid transformations, resulting in incorrect results. Fixes #89101 Release note (bug fix): Fixed a bug that has existed since v2.1.0 where queries containing a subquery with EXCEPT could produce incorrect results. This could happen if the optimizer could guarantee that the left side of the EXCEPT always returned more rows than the right side. In this case, the optimizer made a faulty assupmtion that the EXCEPT subquery always returned at least one row, which could cause the optimizer to perform an invalid transformation, possibly causing the full query to return incorrect results.
Parameters:
ROACHTEST_cloud=gce
,ROACHTEST_cpu=4
,ROACHTEST_encrypted=false
,ROACHTEST_ssd=0
Help
See: roachtest README
See: How To Investigate (internal)
This test on roachdash | Improve this report!
Originally posted by @cockroach-teamcity in #88993 (comment)
Jira issue: CRDB-20119
The text was updated successfully, but these errors were encountered: