-
Notifications
You must be signed in to change notification settings - Fork 2.6k
568 operation converter optimizer #9843
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
Conversation
…lled in the optimizer. GetTableReferences(), used in the join order optimizer, relies on the types array having elements. The Operation Converter calls resolveTypes.
…might need to rebind everything if I do 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.
Thanks for the PR! I'm not too sure about doing this replacement in the optimization phase. It seems to me that we now have two places where EXCEPT/INTERSECT are translated into anti/semi joins - one in the physical planner (plan_set_operation.cpp
) and one in this optimizer. I would propose replacing the physical planner one with this implementation entirely, and doing this replacement in the logical planning phase instead.
…ening correlated subqueries
Closing this as it needs more work |
Convert Intersect and Except into Semi and Anti Joins in the optimizer. This allows the join order optimizer to better predict the cardinality of the the operators.
Eventually the join order optimizer will be able to better predict the cardinality of the semi join, then the cardinality of the set operation.
For
INTERSECT ALL
andEXCEPT ALL
the cardinality estimator can just use logic used to predict the cardinality of a semi join or of an anti join.