From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Ron <ronljohnsonjr@gmail.com>, pgsql-admin@lists.postgresql.org
Subject: Re: [**EXTERNAL**] Re: [pgsql-admin] "Soft-hitting" the 1600 column
 limit
In-reply-to: 
 <CAKFQuwYfzC9yZa=tD57D361S6vBZLg=n-jrsVMpto-jjZGv=UQ@mail.gmail.com>
References: 
 <CACq6szQbQDG6_mThyH32=6J0e99-KdqOrhZMm9QwvGoVFzNbBw@mail.gmail.com>
 <CAOC+FBXehj4X2DMfytnPKHRWrWWZjq1G9OfUXsMop5Tex7hrvg@mail.gmail.com>
 <3C61E858-5CA7-405D-B32A-B4C89D1AC62E@elevated-dev.com>
 <CACq6szR7Q--tw67ZJL4-T59oAXCLXgmCDFVh=FunY3N4HCDLXg@mail.gmail.com>
 <CAOC+FBX6JLtcz-vO7K1rB-qmn23MyVgHya5xgcYLX-yUYoM_xw@mail.gmail.com>
 <05FBE51B-5256-4756-8AE2-98850D3163AF@ciena.com>
 <44426d65-82a6-3ac5-958e-e7582ecaa7bd@gmail.com>
 <CAKFQuwYfzC9yZa=tD57D361S6vBZLg=n-jrsVMpto-jjZGv=UQ@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Wed, 06 Jun 2018 16:35:20 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <7369.1528328667.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 06 Jun 2018 19:44:27 -0400
Message-ID: <7370.1528328667@sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Jun 6, 2018 at 4:15 PM, Ron <ronljohnsonjr@gmail.com> wrote:
>> To my mind, it makes perfect sense for columns to persist in the table
>> structure when dropped=E2=80=A6the only question I have is whether the =
column would
>> survive a VACUUM FULL?  i.e. if the table is rewritten after the column=
 is
>> dropped, would that change things?

> A cursory skim of cluster.c, plus general reasoning, leads me to think
> that the extent of the smarts of the table rewrite (for vacuum full at
> least, not cluster) is to evaluate headers for visibility and omit copyi=
ng
> the physical tuples to the new heap.  The contents of each tuple are
> otherwise copied as-is (except toast pointers...).  So, yes, the variant

No; values in dropped columns get replaced by nulls during a table rewrite=
.
See reform_and_rewrite_tuple(), whose comments say

 * We cannot simply copy the tuple as-is, for several reasons:
 *
 * 1. We'd like to squeeze out the values of any dropped columns, both
 * to save space and to ensure we have no corner-case failures. (It's
 * possible for example that the new table hasn't got a TOAST table
 * and so is unable to store any large values of dropped cols.)
 *
 * 2. The tuple might not even be legal for the new table; this is
 * currently only known to happen as an after-effect of ALTER TABLE
 * SET WITHOUT OIDS.
 *
 * So, we must reconstruct the tuple from component Datums.

Likewise, dropped columns get replaced by nulls when an existing
tuple is updated.

So, while the dropped column never disappears from the table's structure,
over time the space it consumed goes away.

			regards, tom lane