Re: Dropping column from big table

From: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Dropping column from big table
Date: 2024-07-13 22:05:45
Message-ID: 20240713220545.cgjghaggksov3xkt@hjp.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

The documentation also mentions some cases where the table is not
rewritten, so maybe some not explicitely mentioned options rewrite the
table, too.

I would especially expected ALTER TABLE ... CLUSTER to do this, but if
VACUUM FULL preserves the (former) content of dropped columns, maybe
CLUSTER does, too?

hp

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2024-07-15 11:53:25 Re: Dropping column from big table
Previous Message azeem subhani 2024-07-13 11:33:11 pg_rewind Issue: Trying to read Incorrect WAL file for checkpoint record