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
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 |