[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625379#comment-16625379
]
Lars Hofhansl commented on PHOENIX-4815:
----------------------------------------
As a general comment, I think Phoenix has to get better in flexible schema
management. If we have a PB sized table with many billions of rows, you can't
go through and update/delete, etc, columns in all these rows.
Instead we should (1) mark columns for deletion and simply not return them in
any queries, (2) add default values (without materializing them, but adding
them at runtime), and (3) rename columns without touching the data. Lastly (4)
we can have way during compactions to clean up data or materialize defaults if
needed.
This is big data after all, we cannot say "BigData" and "change all rows" in
the same sentence all the time :)
I realize some of these are tricky, both client and server have to know about
schema changes. Perhaps with the new column naming we could simply forgot
columns from the schema, and or add new ones with defaults.
> support alter table modify column
> ----------------------------------
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 4.12.0, 4.13.0, 4.14.0
> Reporter: Jaanai
> Assignee: Jaanai
> Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
> table_name
> modify
> column_name datatype;
> {code}
> reference link:
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2103956
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
