Re: table inheritance versus column compression and storage settings
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-05T04:26:27Z
Lists: pgsql-hackers
On Mon, Dec 4, 2023 at 4:23 PM Peter Eisentraut <peter@eisentraut.org> wrote: > > 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. Incidentally I was looking at that code yesterday and had the same thoughts. > > 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. Looks fine to me. > - When inheriting from multiple parents with different settings, an > explicit setting in the child is required. When no explicit setting for child is specified, it will throw an error as it does today. Right? -- Best Wishes, Ashutosh Bapat
Commits
-
Revert "Improve compression and storage support with inheritance"
- 74563f6b9021 17.0 landed
-
Improve compression and storage support with inheritance
- 0413a556990b 17.0 landed
-
Delay build of Memoize hash table until executor run
- 57f59396bb51 17.0 cited
-
Fix locking when fixing an incomplete split of a GIN internal page
- 6a1ea02c491d 17.0 cited