phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3741) Provide facility to copy a table
Date Thu, 16 Mar 2017 20:11:41 GMT


Samarth Jain commented on PHOENIX-3741:

Dup of PHOENIX-3645?

> Provide facility to copy a table
> --------------------------------
>                 Key: PHOENIX-3741
>                 URL:
>             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

View raw message