Date: Mon, 15 Jul 2024 16:27:44 +0200
From: "Peter J. Holzer" <hjp-pgsql@hjp.at>
To: pgsql-general@lists.postgresql.org
Subject: Re: Dropping column from big table
Message-ID: <20240715142744.7e7a3wtdfxinochf@hjp.at>
Mail-Followup-To: pgsql-general@lists.postgresql.org
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="cz2bpzg3kw4qj275"
Content-Disposition: inline
In-Reply-To: <f70b1f5c575497a615c797588964d3c21823ef7e.camel@cybertec.at>
Archived-At: <https://www.postgresql.org/message-id/20240715142744.7e7a3wtdfxinochf%40hjp.at>
Precedence: bulk


--cz2bpzg3kw4qj275
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2024-07-15 13:53:25 +0200, Laurenz Albe wrote:
> On Sun, 2024-07-14 at 00:05 +0200, Peter J. Holzer wrote:
> > On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> > > Dropping a column is fast, but doesn't reclaim the space.
> > > VACUUM won't block anything, but won't reclaim the space.
> > > VACUUM (FULL) will block everything, but will also not reclaim the sp=
ace.
> > >=20
> > > You'd need to use a form of ALTER TABLE that rewrites the table,
> > > as indicated in the documentation.
> >=20
> > Unfortunately the documentation indicates very little. It mentions that
> > the table will be rewritten with
> >=20
> > * SET ACCESS METHOD
> > * a volatile DEFAULT
> > * changing the type of an existing column (unless binary coercible)
> >=20
> > All three change something which you probably don't want to change.
>=20
> Hm, true.
>=20
> You can always do
>=20
>   UPDATE tab SET id =3D id;
>=20
> followed by
>=20
>   VACUUM (FULL) tab;

Yes, that should work. It needs about twice the size of the table in
temporary space, though.

Since the OP wrote that the table is "daily ... and 90 partitions"
(which understand that there is one partition per day and partitions are
kept for 90 days) it might be better to just wait. After 90 days all the
partitions with the obsolete column will be gone.

        hp

--=20
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

--cz2bpzg3kw4qj275
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmaVMdsACgkQ8g5IURL+
KF1R9w/+IFec+DjbWH1pBnQdRPpEeGy4CsNDd6noH0uSaxlgwiXdzURhb6GjObw8
tDQsLv7hvhNIgHxBB9Btk8atykkO927hVyHwJqd4bxqQfeB+weMzboe4z4+fdZk5
0LHfA8lGMBhmQRit1xdGRh+sBtGw9IPSCsaGg5BvTm0WP4DXbXJbphYpy64ccoM9
w5rqcaedQ1ERhHddoA7ASjHxZSxDCMpojROWOl2D0y3XAQXemd/Y0DWFsKLyGIun
zes7xjx+x9Ewz1GfC9sxBoTWCsikAI9jQjEdQYfQcGJM5j51A5z7EhRXIYyRF6Js
KfIL2Hda+gTgkI1acOLNqXBPa/fEnoHAgMJGKntQTwoIomtjLW7mKHctxC5Odjko
YqehTLUtKFD8wesdaeANQOZch75O+BQF0yRt9J3aLvksF4H4FhAXLmP1uWboDgO4
mdzsin7vzWCimLcKqycA5GPUs2Cw7TSIETLA12QWzL215Qt0+soVjJ6ld8935C6H
LbVj105vPX4yTVTStHXAzKSvHAjHIjEq8U08WH2QV05X2EPQLmWausi5XZBt3QnB
eBgMqvwN4r/mqq5zI8Rug0hvXDVlkbNjQXsSqVE66LF+DoKCgB4cn644qUtLwCoM
gIFAD2qRxJhyHMhnPLDripGfCcC6kKVwKD17gvd2d4DMoppHvBg=
=3QOr
-----END PGP SIGNATURE-----

--cz2bpzg3kw4qj275--