You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a table with a column of type character varying(100) and want to increase that to a bigger maximum length, e.g. character varying(500). The table has compression enabled and therefore we are not allowed to change the type for this column unless we decompress everything. Decompressing everything is not an option since it would take ages.
Proposal:
Since the change is about increase of length and targets a variably sized column, it should not impose any data changes. Hence, from a non-technical view it should be possible with existing compressed data.
I propose to specifically identify and allow non-truncating definition changes like this on compressed tables.
Another non-truncating change would be allowing NULL on a previously non-nullable column.
Possible extended proposal:
This would obviously also be desirable on other non-truncating changes to fixed-size columns (e.g. int32 to int64, char(10) to char(20)), where no changes to the values result from the size change. However, in these cases the size of the stored data changes, so I'd expect this to be a bigger problem (unless this is irrelevant for compressed data storage for some reason ...).
Final appeal:
Please note that while the impact of this change might look small, at the moment any definition change like the above would require to decompress all compressed chunks in a table, which in many cases will take ages or not be an option at all. If there is a solution even only for the increase of variably sized columns, this will already save loads of time for decompression and/or pain to write workarounds ...
Implementation challenges
No response
The text was updated successfully, but these errors were encountered:
I have a similar request but going the opposite direction - wanting to modify a column from numeric to real on a compressed hypertable. I understand this is a truncating change though and so can make a separate enhancement request if that makes more sense.
What type of enhancement is this?
Refactor
What subsystems and features will be improved?
Command processing, Compression
What does the enhancement do?
Problem:
We have a table with a column of type
character varying(100)
and want to increase that to a bigger maximum length, e.g.character varying(500)
. The table has compression enabled and therefore we are not allowed to change the type for this column unless we decompress everything. Decompressing everything is not an option since it would take ages.Proposal:
Since the change is about increase of length and targets a variably sized column, it should not impose any data changes. Hence, from a non-technical view it should be possible with existing compressed data.
I propose to specifically identify and allow non-truncating definition changes like this on compressed tables.
Another non-truncating change would be allowing NULL on a previously non-nullable column.
Possible extended proposal:
This would obviously also be desirable on other non-truncating changes to fixed-size columns (e.g. int32 to int64, char(10) to char(20)), where no changes to the values result from the size change. However, in these cases the size of the stored data changes, so I'd expect this to be a bigger problem (unless this is irrelevant for compressed data storage for some reason ...).
Final appeal:
Please note that while the impact of this change might look small, at the moment any definition change like the above would require to decompress all compressed chunks in a table, which in many cases will take ages or not be an option at all. If there is a solution even only for the increase of variably sized columns, this will already save loads of time for decompression and/or pain to write workarounds ...
Implementation challenges
No response
The text was updated successfully, but these errors were encountered: