[jira] [Comment Edited] (PHOENIX-3741) Provide facility to copy a table

["James Taylor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928765#comment-15928765 ] 

James Taylor edited comment on PHOENIX-3741 at 3/16/17 8:07 PM:
----------------------------------------------------------------

FYI - [~lhofhansl] - an interesting idea. Kind of what we were going for supporting the running ofUPSERT SELECT asynchronously (PHOENIX-3211) which I think we kind of wouldn't really need (at least it'd be a much lower priority).


was (Author: jamestaylor):
FYI - [~lhofhansl] - an interesting idea. Kind of what we were going for support running UPSERT SELECT asynchronously (PHOENIX-3211) which I think we kind of wouldn't really need (at least it'd be a much lower priority).

> Provide facility to copy a table
> --------------------------------
>
>                 Key: PHOENIX-3741
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3741
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>
> Original idea by [~samarthjain] - just want to capture it here as I think it's very promising. There are often reasons to copy an entire table - for example to take advantage of a new feature which is only supported for new tables (i.e. column encoding and immutable storage scheme). One issue which is tricky is ensuring that no rows are missed, since while the copy is occurring, the table may be taking writes. To solve this, we can capitalize on our index building logic. Under-the-covers, we could create the target table as an "index" on the source table but keep the same exact schema for both the primary key (as the indexed columns) and non primary key columns (as covered columns). Once an index is created, future writes would be propagated to both the source and target (i.e. index) table. Upon completion, we could manually tweak the table type and ensure the correct coprocessors are in-place before allowing direct writes to the table. The other nice aspect of this approach is that we could copy the table synchronously or asynchronously since we already support that today. We could also potentially block DDL changes to the source table while the copy statement is running.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)