Search Postgresql Archives

Re: Dropping column from big table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux