You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: split INSERT .. SELECT * FROM unnest(..) - #1988
This PR adds functionality to split INSERT INTO <sharded table> .. SELECT * FROM unnest($1, ..) by how the rows from unnest resolve to Shards if split_inserts is set to rewrite
E.g., if we have a statement such as
INSERT INTO sharded (id, value) SELECT * FROM unnest($1::pg_catalog._int8, $2::pg_catalog._text)
with $1 = {1,2,3,4} and $2 = {a,b,c,d}, Postgres inserts the rows (1, a), (2, b), (3, c) and (4, d).
If we get one of these INSERTs, we split the INSERT by shard, as follows:
we decode the arrays from the Bind (in text or binary format) using the element types from the casts (e.g., int8 from pg_catalog._int8).
then, we route all of the rows one at a time with the unnest(..) arguments matched to the INSERT columns by position
finally, we send the original INSERT to all shards that the router found. To make this work correctly, we cut the arrays from the Bind down to the rows that belong on the shard. E.g., if ids 1 and 3 belong on Shard A, Shard A will get $1 = {1,3} and $2 = {a,c}, and Shard B will get $1 = {2,4} and $2 = {b,d}.
Otherwise notable:
If the arrays have different lengths, unnest(..) will pad the shorter arrays with NULLs so we use the length of the longest array as the number of rows and send NULLs for the missing elements.
We only split SELECT * FROM unnest(..) where all arguments are parameters with a cast to an array type that we can decode (e.g., _bool, _int2, _int4, _int8...) without any clauses (e.g., LIMIT) present.
Future performance work: currently, We route the rows one at a time (one Router::query call per row), which is slow for large arrays. We could compute the shards of the rows from the array of the sharding key directly instead.
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
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.
This PR adds functionality to split
INSERT INTO <sharded table> .. SELECT * FROM unnest($1, ..)by how the rows from unnest resolve to Shards if split_inserts is set to rewriteE.g., if we have a statement such as
with
$1 = {1,2,3,4}and$2 = {a,b,c,d}, Postgres inserts the rows(1, a),(2, b),(3, c)and(4, d).If we get one of these INSERTs, we split the INSERT by shard, as follows:
int8frompg_catalog._int8).$1 = {1,3}and$2 = {a,c}, and Shard B will get$1 = {2,4}and$2 = {b,d}.Otherwise notable:
SELECT * FROM unnest(..)where all arguments are parameters with a cast to an array type that we can decode (e.g.,_bool,_int2,_int4,_int8...) without any clauses (e.g., LIMIT) present.Router::querycall per row), which is slow for large arrays. We could compute the shards of the rows from the array of the sharding key directly instead.