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

  1. Revert "Improve compression and storage support with inheritance"

  2. Improve compression and storage support with inheritance

  3. Delay build of Memoize hash table until executor run

  4. Fix locking when fixing an incomplete split of a GIN internal page