[
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)
