Re: How to reclaim the space of dropped columns of a table? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: How to reclaim the space of dropped columns of a table?
Date
Msg-id 20956.1563209526@sss.pgh.pa.us
Whole thread Raw
In response to Re: How to reclaim the space of dropped columns of a table?  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Jul 15, 2019 at 8:42 AM Paul Guo <pguo@pivotal.io> wrote:
>> This seems to a bit vague for users (how to rewrite but keep the table
>> definition) and it seems to still keep the dropped columns (though with
>> null). Isn't it better to leave the functionality to command like 'vacuum
>> full' to completely remove the dropped columns (i.e. no dropped columns in
>> pg_attributes and no null values for dropped columns for a table)?

> Probably.  But it doesn't seem worth the effort to accomplish.  The amount
> of data involved (and VACUUM FULL does perform the table rewrite described)
> to represent the missing column is minimal.

Completely removing a column is pretty impractical, because that would
require renumbering subsequent columns, which would have potential impacts
throughout the system catalogs (for example, in views referencing this
table, or foreign key info for other tables referencing this one).

There's been repeated discussion about separating the concepts of
a column's (a) permanent identifier for catalog purposes, (b)
physical position in table rows, and (c) logical position as
reflected in "SELECT *" ordering.  If we had that, this sort of
thing would be much more practical.  But making that happen is a
large and very bug-prone task, so it hasn't been done (yet).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Andrey Lepikhov
Date:
Subject: Re: Insecure initialization of required_relids field