Re: Inconsistency between Compression and Storage for Foreign Tables
От | Sami Imseih |
---|---|
Тема | Re: Inconsistency between Compression and Storage for Foreign Tables |
Дата | |
Msg-id | CAA5RZ0tZLT4oVbPxx2Z34SnSM-6gkccqbgfJqTwTQbVSQGJjmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Inconsistency between Compression and Storage for Foreign Tables (Zhang Mingli <zmlpostgres@gmail.com>) |
Ответы |
Re: Inconsistency between Compression and Storage for Foreign Tables
|
Список | pgsql-hackers |
> This form sets the storage mode for a column. See the similar form of ALTER TABLE for more details. > Note that the storage mode has no effect unless the table's foreign-data wrapper chooses to pay attention to it. Hi, It looks like cb1ca4d [1], from nearly 10 years ago, allowed storage on an FDW to avoid introducing any special handling for foreign tables in the case of inheritance/partitioning, especially when partitions are a mixture of both normal and foreign tables. COMPRESSION, on the other hand, did not require special handling because, when you run ALTER TABLE ... COMPRESSION on a parent table, the setting is only applied to the parent table and to new partitions created afterward. Existing partitions do not inherit the setting, as somewhat described here [2]: "but the configured value will be inherited by newly-created partitions." IMO, the correct approach is to disallow the STORAGE parameter on foreign tables, which is what [1] tried to avoid for some reason. However, since this behavior has existed for over 10 years, I don’t think we should change it. Maybe someone has a different opinion about this, and we should disallow setting STORAGE on an fdw table in future versions. I am not in favor of allowing compression to be set on a foreign table just for the sake of consistency, when there is no reason for this on a foreign table. [1] https://github.com/postgres/postgres/commit/cb1ca4d800621dc [2] https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-SET-COMPRESSION Regards, Sami
В списке pgsql-hackers по дате отправления: