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

sql: support UPDATE ... FROM #7841

Closed
maddyblue opened this issue Jul 14, 2016 · 11 comments
Closed

sql: support UPDATE ... FROM #7841

maddyblue opened this issue Jul 14, 2016 · 11 comments
Assignees
Labels
A-sql-optimizer SQL logical planning and optimizations. A-sql-pgcompat Semantic compatibility with PostgreSQL A-sql-semantics C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) X-anchored-telemetry The issue number is anchored by telemetry references.

Comments

@maddyblue
Copy link
Contributor

maddyblue commented Jul 14, 2016

(edit @knz 2018-05-19)

UPDATE X SET ... = Y FROM Z
https://www.postgresql.org/docs/10/static/sql-update.html

performs (I think) a lateral join of X with Z and then makes the values computed by Z available for the scalar expressions in Y, to serve as values to update.

Full support for the feature needs support for correlated subqueries #3288 and lateral joins #24560.

Reduced support when the relational expression Z is uncorrelated (a common case) could perhaps be added with a simple join, although additional execution machinery is still needed to propagate the PK prefixes for the X operand to the join through up to the point UPDATE can pick them up.

As to which rows get updated:

  • Rows of table X that don't match in the join are not updated.
  • Rows that match in X with the join on Z are updated. If there is just 1 matching row (or if there is a cross join but the right operand has just 1 row), then the situation is clear. I am not exactly sure what happens if there are multiple rows.

The work to be done is twofold:

  • construct (and properly optimize) the data source with a join when FROM is specified
  • plumb the PK values properly so that UPDATE still has PKs to work with.
@maddyblue maddyblue added the C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) label Jul 14, 2016
@maddyblue
Copy link
Contributor Author

See #7247 when fixing this issue.

@aitjcize
Copy link

aitjcize commented Nov 8, 2017

any updates on when this will be supported?

@dianasaur323
Copy link
Contributor

cc @awoods187

@awoods187
Copy link
Contributor

awoods187 commented Nov 9, 2017

@aitjcize we will not be including this in our upcoming April release. I'd love to hear more about your use case to understand your need for this feature. This will help us prioritize for future roadmap inclusion

@aitjcize
Copy link

aitjcize commented Nov 9, 2017

For our specific use case, we simply want to save as much query as possible. We are using UPDATE table SET ... FROM table old_table WHERE ... RETURNING old_table.X to return pre-update value after update.

@jviksne
Copy link

jviksne commented Jan 14, 2018

I would also like to vote for this to be implemented. I need to do some conditional operations on a sum of values from child records. In PostgreSQL I can do it in a single query, while I guess in CockroachDB I will need to split it into multiple separate ones.

The query looks something like this (with simplified conditions here):
UPDATE my_table SET child_cost=
CASE WHEN subq.child_cost_sum < cost THEN subq.child_cost_sum ELSE cost END
FROM (SELECT sum(cost) AS child_cost_sum FROM my_table WHERE parent_id=123) AS subq;

@jordanlewis jordanlewis added the E-starter Might be suitable for a starter project for new employees or team members. label Apr 26, 2018
@knz knz added A-sql-pgcompat Semantic compatibility with PostgreSQL and removed E-starter Might be suitable for a starter project for new employees or team members. labels May 19, 2018
@knz
Copy link
Contributor

knz commented May 19, 2018

I have extended the top description of the issue to detail the work that needs to be done. It's not super simple but it's not fundamentally difficult either. Probably reasonable to table for CRDB 2.2. (edit 2018-10-19 I don't know actually)

@awoods187
Copy link
Contributor

top requested feature based on telemetry data

@knz
Copy link
Contributor

knz commented Nov 16, 2018

Discussed this with @andy-kimball yesterday - Andy confirmed that once the opt framework knows about mutations, planning update...from will be a natural extension of the support for correlated subqueries and lateral joins.

(Of course ensuring the statement is recognized in the first place will still require some extra work)

@knz knz added A-sql-optimizer SQL logical planning and optimizations. X-anchored-telemetry The issue number is anchored by telemetry references. labels Nov 16, 2018
@knz
Copy link
Contributor

knz commented Nov 30, 2018

@justinj
Copy link
Contributor

justinj commented Jul 2, 2019

https://www.postgresql.org/docs/9.5/sql-update.html

Re: what happens if multiple rows match:

When a FROM clause is present, what essentially happens is that the target table is joined to the tables mentioned in the from_list, and each output row of the join represents an update operation for the target table. When using FROM you should ensure that the join produces at most one output row for each row to be modified. In other words, a target row shouldn't join to more than one row from the other table(s). If it does, then only one of the join rows will be used to update the target row, but which one will be used is not readily predictable.

Because of this indeterminacy, referencing other tables only within sub-selects is safer, though often harder to read and slower than using a join.

@ridwanmsharif ridwanmsharif self-assigned this Jul 24, 2019
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 1, 2019
Addresses cockroachdb#7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

TODO:
 - [ ] Prune the passthrough columns in the returning clause.

Release note: None
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 1, 2019
Addresses cockroachdb#7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

TODO:
 - [ ] Prune the passthrough columns in the returning clause.

Release note: None
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 1, 2019
Addresses cockroachdb#7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

TODO:
 - [ ] Prune the passthrough columns in the returning clause.

Release note: None
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 2, 2019
Addresses cockroachdb#7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

Release note: None
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 5, 2019
Addresses cockroachdb#7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

Release note: None
craig bot pushed a commit that referenced this issue Aug 5, 2019
39202: opt, sql: support `UPDATE ... FROM` statements r=ridwanmsharif a=ridwanmsharif

Addresses #7841.

This change adds support for `UPDATE ... FROM` statements.
The FROM clause tables are joined together with the target
table and is used as input for the update. Furthermore, the
RETURNING clause can reference any table in the FROM clause.

Release note: None

Co-authored-by: Ridwan Sharif <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sql-optimizer SQL logical planning and optimizations. A-sql-pgcompat Semantic compatibility with PostgreSQL A-sql-semantics C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) X-anchored-telemetry The issue number is anchored by telemetry references.
Projects
None yet
Development

No branches or pull requests

10 participants