-
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: support all DML statements in CBO and deprecate DML part of HP #34848
Comments
@awoods187 I repurposed the issue a bit to focus on removing the HP for DML and relational expressions inside other statements. |
I ran the logic tests and printed out errors for all statements that were not supported by the optimizer but executed successfully with the HP:
I think we may want to support some of the |
Thanks @rytaft! Yeah I agree on the SHOW commands, they fall under "Statements that can be used as a data source for a SELECT". I added a bullet for the Scatter, etc. |
I looked through the grammar. A few other statements that incorporate a select clause: Statements that can be |
We currently support all preparable statements as row sources using the `SELECT FROM [ ... ]` syntax. Many of these statements are not really useful here and each one will require work when we deprecate the heuristic planner. This change restricts the set of statements that can be used as row sources to DML statements, SHOW statements, and EXPLAIN. There were no specific tests for this functionality for any of the statements that were removed. If we find that we need any of them, we can add them back on a case-by-case basis. Release note (sql change): Only SELECT, INSERT, UPDATE, UPSERT, DELETE, SHOW, EXPLAIN are supported as data sources using the `SELECT ... FROM [ ... ]` syntax. Informs cockroachdb#34848.
36977: sql: restrict statements that can be used as row sources r=RaduBerinde a=RaduBerinde We currently support all preparable statements as row sources using the `SELECT FROM [ ... ]` syntax. Many of these statements are not really useful here and each one will require work when we deprecate the heuristic planner. This change restricts the set of statements that can be used as row sources to DML statements, SHOW statements, and EXPLAIN. There were no specific tests for this functionality for any of the statements that were removed. If we find that we need any of them, we can add them back on a case-by-case basis. Release note (sql change): Only SELECT, INSERT, UPDATE, UPSERT, DELETE, SHOW, EXPLAIN are supported as data sources using the `SELECT ... FROM [ ... ]` syntax. Informs #34848. Co-authored-by: Radu Berinde <[email protected]>
It turns out that we don't care about most of these, and they were supported just as a consequence of how the grammar was written. #36977 reduces this list to SHOW variations. |
38445: opt: opaque relational operator r=RaduBerinde a=RaduBerinde #### optgen: panic early on unknown type I had a case where adding an unknown type to a private resulted in a cryptic segmentation violation. Normally an unknown type would generate an error in the validator but in this case we don't get that far. This change makes optgen panic immediately when it encounters an unknown type. Release note: None #### opt: opaque relational operator We introduce `OpaqueRel`: a relational operator which contains a plan generated outside of the optimizer. External code registers an "opaque handler" for a specific AST node type; the opaque handler generates the plan and returns it as "opaque metadata". The opaque metadata is later passed to the exec factory. In this change we add opaque handlers for all remaining SHOW variants which use a custom planNode (and thus cannot be `delegate`d). Informs #34848. Release note: None Co-authored-by: Radu Berinde <[email protected]>
38585: opt: add support for ALTER TABLE/INDEX SPLIT AT r=RaduBerinde a=RaduBerinde #### opt: return index ordinal from ResolveTableIndex Release note: None #### optbuilder: add wrapper for building typed scalar Release note: None #### opt: add support for ALTER TABLE/INDEX SPLIT AT Adding optimizer support for `tree.Split`. This statement has a relational input, so it can't be implemented as an "opaque". Release note: None Informs #34848. Co-authored-by: Radu Berinde <[email protected]>
38653: opt: support ALTER TABLE UNSPLIT and EXPERIMENTAL_RELOCATE r=RaduBerinde a=RaduBerinde #### opt: support ALTER TABLE UNSPLIT Support for ALTER TABLE UNSPLIT (which has two variants). Release note: None #### opt: support EXPERIMENTAL_RELOCATE Also fix the formatting of details for split/unsplit. Release note: None Informs #34848. Co-authored-by: Radu Berinde <[email protected]>
Remaining features that need to be implemented before we retire HP support for DML statements:
The text was updated successfully, but these errors were encountered: