MIME-Version: 1.0
In-Reply-To: <CAD=mzVVTE1Jx0fpsQ=OVW0CL5LiGg_RHA4kq+cbPqTShA5EwVw@mail.gmail.com>
References: <CAD=mzVUGj2Zg0RY9YJwgDzAeghPjuT0FOnNs-aysTBGss87Yyw@mail.gmail.com>
 <f519a562-667c-4a96-9844-a2aaa42928b3@aklaver.com> <CAD=mzVUS8mFK42zmVUUC3JkiN=9QSUZ_Qxayd6=KJwbqdd0HzA@mail.gmail.com>
 <CANzqJaBAOzCjXaBFLa6cYweVNf5LbBvLYFkWx_hb3YezOP3quw@mail.gmail.com>
 <CAD=mzVXK+4tLMbENMecruPbk8cmeE4smD=ENUrwx5wh4N7hZhA@mail.gmail.com>
 <acc8b587497a65d38fafe4e0030e252eda78398f.camel@cybertec.at>
 <20240713220545.cgjghaggksov3xkt@hjp.at> <f70b1f5c575497a615c797588964d3c21823ef7e.camel@cybertec.at>
 <20240715142744.7e7a3wtdfxinochf@hjp.at> <CAD=mzVW9d0cPfccGVHLvCkcq4Mc-Wg5La3+XAHHEY1AMeOQ_Bw@mail.gmail.com>
 <20240716003731.m75sye7qq74wadhe@hjp.at> <CAD=mzVVTE1Jx0fpsQ=OVW0CL5LiGg_RHA4kq+cbPqTShA5EwVw@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Mon, 15 Jul 2024 21:52:41 -0700
Message-ID: <CAKFQuwZL8jWOX35fSRsMp2tjfGpqsnUgG=cCKuVBen5PC8Jddg@mail.gmail.com>
Subject: Re: Dropping column from big table
To: sud <suds1434@gmail.com>
Cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>, 
	"Peter J. Holzer" <hjp-pgsql@hjp.at>
Content-Type: multipart/alternative; boundary="000000000000a4c676061d561da5"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwZL8jWOX35fSRsMp2tjfGpqsnUgG%3DcCKuVBen5PC8Jddg%40mail.gmail.com>
Precedence: bulk

--000000000000a4c676061d561da5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, July 15, 2024, sud <suds1434@gmail.com> wrote:

>
> However even with "vacuum full", the old rows will be removed completely
> from the storage , but the new rows will always be there with the 'droppe=
d'
> column still existing under the hood along with the table storage,  with
> just carrying "null" values in it. [=E2=80=A6] Is this understanding corr=
ect?
>

No.  The table rewrite process involves creating new tuples that exactly
conform to the current row specification.  The potentially non-null data
present in live tuples for columns that have been dropped are not copied
into the newly constructed tuples.

https://github.com/postgres/postgres/blob/d2b74882cab84b9f4fdce0f2f32e892ba=
9164f5c/src/backend/access/heap/heapam_handler.c#L2499

David J.

--000000000000a4c676061d561da5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, July 15, 2024, sud &lt;<a href=3D"mailto:suds1434@gmail.com">sud=
s1434@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">However even with &quot;vacuum full&quot;, the ol=
d rows will be removed completely from the storage , but the new rows will =
always be there with the &#39;dropped&#39; column still existing under the =
hood along with the table storage,=C2=A0 with just carrying &quot;null&quot=
; values in it. [=E2=80=A6] Is this understanding correct?<br></div></div><=
/div></blockquote><div><br></div><div>No.=C2=A0 The table rewrite process i=
nvolves creating new tuples that exactly conform to the current row specifi=
cation.=C2=A0 The potentially non-null data present in live tuples for colu=
mns that have been dropped are not copied into the newly constructed tuples=
.</div><div><br></div><div><a href=3D"https://github.com/postgres/postgres/=
blob/d2b74882cab84b9f4fdce0f2f32e892ba9164f5c/src/backend/access/heap/heapa=
m_handler.c#L2499">https://github.com/postgres/postgres/blob/d2b74882cab84b=
9f4fdce0f2f32e892ba9164f5c/src/backend/access/heap/heapam_handler.c#L2499</=
a><br></div><div><br></div><div>David J.=C2=A0</div>

--000000000000a4c676061d561da5--