sql: pass COPY typed tuples through optimizer untouched #81731
Assignees
Labels
A-migrations
Migrating to CRDB from another database vendor
C-enhancement
Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
T-sql-queries
SQL Queries Team
Comments
cucaroach
added
C-enhancement
cucaroach
changed the title
cucaroach
added a commit
to cucaroach/cockroach
that referenced
this issue
Aug 16, 2022
As a new/half supported feature COPY FROM STDIN support is under tested. Add tests and a simple benchmark to pave the way for enhancements and optimizations. Assists: cockroachdb#81731 Release note: None Release justification: non-production code change
craig bot
pushed a commit
that referenced
this issue
Aug 16, 2022
85462: sql: unit test, benchmark and logictests for COPY r=cucaroach a=cucaroach As a new/half supported feature COPY FROM STDIN support is under tested. Add tests and a simple benchmark to pave the way for enhancements and optimizations. Assists: #81731 Release note: None Release justification: non-production code change 86043: release: build linux-arm binary for release r=rail,jlinder a=rickystewart Release note (build change): build *experimental* Linux ARM64 binary Release justification: build *experimental* Linux ARM64 binary for release 86169: api: update database parameter name r=maryliag a=maryliag Previously, we were calling the database parameter in `SqlExecutionRequest` as `database_name`, instead of the correct `database`. This commit updates the parameter name to the correct one. Release note (bug fix): Use proper parameter name for database on SQL api Release justification: bug fix 86192: sql/schemachanger: fixed a ordial number bug in ALTER PRIMARY KEY r=Xiang-Gu a=Xiang-Gu Previously, we had a bug in ALTER PRIMARY KEY such that when the new primary key is a superset of the old primary key, we incorrectly gave ordinal numbers to IndexColumn elements. This PR fixed it and added a few logic tests for cases when the new primary key intersects with the old primary key. Fixes: #85877 Release note: None Release justification: fixed a bug that was revealed in roachtest failure (issue #85877) Co-authored-by: Tommy Reilly <[email protected]> Co-authored-by: Ricky Stewart <[email protected]> Co-authored-by: Marylia Gutierrez <[email protected]> Co-authored-by: Xiang Gu <[email protected]>
18 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Inspired by /issues/52071
just create and cache the memo for a prepared insert. At first we could just execute each row in a loop but we should look at how to push the entire batch down to the KV boundary. @RaduBerinde outlines one possible way to do that in 52071. Ideally the COPY path and prepared insert batches can benefit from the same set of optimizations. Even further down the road would it make sense to have an enhanced (distsql based?) batch insert implementation that knew about cluster topology, did sorting and pre-range splitting etc to get around single node bottlenecks, this could potentially borrow/share code from bulk I/O.After some thought it makes more sense to just pass the typed tuples through the optimizer and maybe later we can come back and use this approach for prepared statements.
Jira issue: CRDB-16061
Epic CRDB-14916
The text was updated successfully, but these errors were encountered: