Repository navigation
feat: split INSERT .. SELECT <columns> FROM unnest(..) into sharded tables (not only SELECT *) - #2000
Merged
Merged
Conversation
jkaczman
force-pushed
the
jk-unnest-select-targets
branch
from
November 9, 2026 21:34
ae2d77f to
449cc55
Compare
Contributor
|
Metal bench (arm64) failed. build failed to run. LogsRan 00d0ea1 on m8g.metal-24xl (spot). |
Contributor
|
Metal bench (x86) failed. build failed to run. LogsRan 00d0ea1 on c7i.metal-48xl (on-demand). |
jkaczman
force-pushed
the
jk-unnest-select-targets
branch
4 times, most recently
from
November 9, 2026 22:01
9762111 to
df1af3b
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
jkaczman
force-pushed
the
jk-unnest-select-targets
branch
2 times, most recently
from
November 9, 2026 23:52
456e183 to
86e48ab
Compare
…ables (not only SELECT *)
jkaczman
force-pushed
the
jk-unnest-select-targets
branch
from
November 10, 2026 00:31
86e48ab to
00d0ea1
Compare
jkaczman
added a commit
that referenced
this pull request
Nov 10, 2026
…, SELECT/UPDATE FROM (#2003) Works off the previous changes implementing splitting INSERT with unnest (#1988, #2000) to now implement this unnest functionality to be used when re-writing subqueries (as opposed to re-writing the SQL to have an explicit VALUES clause with all the DataRows inlined) when we send the subquery data rows back to Postgres in the outer statement to be evaluated. This should be a considerable speedup vs. before; if we had 10,000 DataRows returned, it's much cheaper to include the data in an array in a Bind parameter vs. creating a new SQL statement with 10,000 tuples and deparsing it. Not handled for WHERE clause yet. Will follow up.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#1988, the previous PR implementing unnest split, only handled splitting when the SELECT for the INSERT was
SELECT *, e.g., inINSERT INTO <sharded table> .. SELECT * FROM unnest($1, ..). As this is unimplemented functionality, since #1987, we (correctly) returned an error for this, as this is one of the cases not handled by that previous PR (anything other thanSELECT *).Now, as an extension of #1988, this PR also splits these unnest INSERTs when the SELECT explicitly lists the output columns of unnest(..) one at a time instead of
*, as well as when the SELECT includes constants (e.g.,NULL).The motivation for this is fully completing unnest support (instead of VALUES) for re-writing subqueries.
E.g., if we have a statement such as
The subquery support I'm working on for unnest will run
SELECT id, id + 1, NULL FROM suborderson the shards. The shards return some rows, e.g.,(1, 2, NULL),(2, 3, NULL)and(3, 4, NULL). Then, subqueries will send these rows back to the INSERT as unnest(..) arrays. However, the shards return theNULLcolumn with the typetext(default Postgres association for the NULL constant). If we sent theNULLcolumn as an array too, the array would be atext[], and Postgres would return an error when we inserttextinto thebigintcolumnorder_id. Not to mention, this is inefficient. Therefore, I opted when implementing support for this in subqueries to keep the constants in the SELECT as a nice workaround:SELECT *would only return the columns of unnest(..), so there'd be no way for SELECT to include theNULLwithSELECT *without the array mentioned prior. Therefore, we need this PR before subquery support can use unnest(..) to properly split constants apart from the unnest array.To route the rows, this follows the alias
AS u(c1, c2)and the SELECT to find the unnest(..) argument that Postgres uses to insert into the sharding key. Then, the rows are routed as if the client sentINSERT INTO subpackages (id, user_id, order_id) VALUES ($1, $2, NULL).