So I have a table with a large dataset and this table has a three columns that I would like to drop.
The question is: how will Postgres deal with it?
Will it walk through every entry or will it just update mapping info without much overhead?
Can I just make an ALTER TABLE
or should I use swap-table in this particular case?
And, if it makes any difference, all three columns have fixed length (two integers and one numeric).
I'm sorry if it's been asked already, but Google couldn't find any related questions / articles ...
Google may have been useless for this question, but the manual rarely fails:
The
DROP COLUMN
form does not physically remove the column, but simply makes it invisible to SQL operations. Subsequent insert and update operations in the table will store a null value for the column. Thus, dropping a column is quick but it will not immediately reduce the on-disk size of your table, as the space occupied by the dropped column is not reclaimed. The space will be reclaimed over time as existing rows are updated.
And:
To force an immediate rewrite of the table, you can use
VACUUM FULL
,CLUSTER
or one of the forms ofALTER TABLE
that forces a rewrite. This results in no semantically-visible change in the table, but gets rid of no-longer-useful data.
Specifically, the column attisdropped
in the system catalog table pg_attribute
is set to true
.
There are minor side-effects (as Chris pointed out):
Updated or newly inserted rows still store an invisible null value which forces a null bitmap for every new row, even with no null in visible columns. Does not affect existing rows as those keep the original (now invisible) column value.
The null bitmap must be big enough to cover all visible and dropped columns. In corner cases it may be enlarged by this. About effective size:
Dropped columns count against the allowed maximum (which you shouldn't be scraping anyway).
There is currently (Postgres 16) no easy way to get rid of the zombi column completely. The above mentioned table rewrites replace invisible values with null
, which reclaims almost all space but doesn't purge the dropped column from the system catalogs. Not even TRUNCATE
does. Only creating a new table or a dump/restore cycle does that.