table inheritance versus column compression and storage settings
От | Peter Eisentraut |
---|---|
Тема | table inheritance versus column compression and storage settings |
Дата | |
Msg-id | 24656cec-d6ef-4d15-8b5b-e8dfc9c833a7@eisentraut.org обсуждение исходный текст |
Ответы |
Re: table inheritance versus column compression and storage settings
|
Список | pgsql-hackers |
I found the way that MergeAttributes() handles column compression and storage settings very weird. For example, I don't understand the purpose of this error: create table t1 (a int, b text compression pglz); create table t1a (b text compression lz4) inherits (t1); ... ERROR: 42804: column "b" has a compression method conflict DETAIL: pglz versus lz4 or this: create table t2 (a int, b text compression lz4); create table t12 () inherits (t1, t2); ... ERROR: column "b" has a compression method conflict DETAIL: pglz versus lz4 And we can't override it in the child, per the first example. But this works: create table t1a (a int, b text compression lz4); alter table t1a inherit t1; Also, you can change the settings in the child using ALTER TABLE ... SET COMPRESSION (which is also how pg_dump will represent the above constructions), so the restrictions at CREATE TABLE time don't seem to make much sense. Looking at the code, I suspect these rules were just sort of copy-and-pasted from the nearby rules for types and collations. The latter are needed so that a table with inheritance children can present a logically consistent view of the data. But compression and storage are physical properties that are not logically visible, so every table in an inheritance hierarchy can have their own setting. I think the rules should be approximately like this (both for compression and storage): - A newly created child inherits the settings from the parent. - A newly created child can override the settings. - Attaching a child changes nothing. - When inheriting from multiple parents with different settings, an explicit setting in the child is required. Thoughts?
В списке pgsql-hackers по дате отправления: