Re: table inheritance versus column compression and storage settings - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: table inheritance versus column compression and storage settings
Date
Msg-id CAExHW5uH0q810ZZ7ZP2Bvz_aF33yPTUsZ5NNC=yvA1MsVVtDTw@mail.gmail.com
Whole thread Raw
In response to table inheritance versus column compression and storage settings  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: table inheritance versus column compression and storage settings
List 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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: CRC32C Parallel Computation Optimization on ARM
Next
From: Peter Geoghegan
Date:
Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan