Re: Dropping column from big table

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Dropping column from big table
Date: 2024-07-15 11:53:25
Message-ID: f70b1f5c575497a615c797588964d3c21823ef7e.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2024-07-14 at 00:05 +0200, Peter J. Holzer wrote:
> On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> > On Thu, 2024-07-11 at 13:10 +0530, sud wrote:
> > > Dropping will take it's own time for post vacuum however as you
> > > rightly said, it won't be blocking which should be fine. 
> >
> > I am not certain if you understood this correctly.
> >
> > 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 space.
> >
> > You'd need to use a form of ALTER TABLE that rewrites the table,
> > as indicated in the documentation.
>
> Unfortunately the documentation indicates very little. It mentions that
> the table will be rewritten with
>
> * SET ACCESS METHOD
> * a volatile DEFAULT
> * changing the type of an existing column (unless binary coercible)
>
> All three change something which you probably don't want to change.

Hm, true.

You can always do

UPDATE tab SET id = id;

followed by

VACUUM (FULL) tab;

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-07-15 14:04:39 How does this FK constraint error happen?
Previous Message Peter J. Holzer 2024-07-13 22:05:45 Re: Dropping column from big table