-
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
opt: do not provide project ordering for columns removed when simplified #64444
Conversation
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.
Reviewed 2 of 2 files at r1.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @RaduBerinde)
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.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner)
pkg/sql/opt/ordering/project_test.go, line 81 at r1 (raw file):
Is it worth also adding a data-driven regression test with a SQL query affected by this problem? Or is there no good reproduction? |
Previously, `projectCanProvideOrdering` did not simplify an ordering base on an FD set if the original ordering could be provided, while `projectBuildChildReqOrdering` always attempted to simplify an ordering. In cockroachdb#64342 the behavior of `OrderingChoice.Simplify` changed to remove columns in groups that are not known to be equivalent by the FD. As a result, `projectCanProvideOrdering` could return true in cases where the simplified ordering, with some columns removed, could not be provided, causing `ordering.projectBuildChildReqOrdering` to panic. This commit updates `ordering.projectCanProvideOrdering` so that the ordering is always simplified, matching the behavior of `ordering.projectBuildChildReqOrdering`. Fixes cockroachdb#64399 Release note: None
2c74904
to
6d36413
Compare
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @rytaft)
pkg/sql/opt/ordering/project_test.go, line 81 at r1 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
Is it worth also adding a data-driven regression test with a SQL query affected by this problem? Or is there no good reproduction?
I left it out because its pretty non-sensical and it didn't really belong anywhere. But I found logictest/testdata/logic_test/sqlsmith
which seems like a loving home for it. 🏡
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.
Reviewed 1 of 1 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @mgartner)
pkg/sql/opt/ordering/project_test.go, line 81 at r1 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
I left it out because its pretty non-sensical and it didn't really belong anywhere. But I found
logictest/testdata/logic_test/sqlsmith
which seems like a loving home for it. 🏡
Hehe awesome
TFTRs! bors r+ |
Build succeeded: |
Previously,
projectCanProvideOrdering
did not simplify an orderingbase on an FD set if the original ordering could be provided, while
projectBuildChildReqOrdering
always attempted to simplify an ordering.In #64342 the behavior of
OrderingChoice.Simplify
changed to removecolumns in groups that are not known to be equivalent by the FD. As a
result,
projectCanProvideOrdering
could return true in cases where thesimplified ordering, with some columns removed, could not be provided,
causing
ordering.projectBuildChildReqOrdering
to panic.This commit updates
ordering.projectCanProvideOrdering
so that theordering is always simplified, matching the behavior of
ordering.projectBuildChildReqOrdering
.Fixes #64399
Release note: None