Re: Dropping column from big table - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: Dropping column from big table
Date
Msg-id 20240713220545.cgjghaggksov3xkt@hjp.at
Whole thread Raw
In response to Re: Dropping column from big table  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Dropping column from big table
List 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@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment

pgsql-general by date:

Previous
From: azeem subhani
Date:
Subject: pg_rewind Issue: Trying to read Incorrect WAL file for checkpoint record
Next
From: Laurenz Albe
Date:
Subject: Re: Dropping column from big table