> Updating pg_attribute per se is not so hard --- just store new copies of
> all the rows for the table. However, propagating the changes into other
> places could be quite painful (I'm thinking of column numbers in stored
> constraints, rules, etc).
>
> It seems to me that reducing the column to NULLs already gets you the
> majority of the space savings. I don't think there is a case to be made
> that getting back that last bit is worth the pain involved, either in
> implementation effort or direct runtime costs (do you really want a DROP
> COLUMN to force an immediate rewrite of the whole table?)
OK, sounds fair. However, is there a more aggressive way of reclaiming the
space? The problem with updating all the rows to null for that column is
that the on-disk size is doubled anyway, right? So, could a VACUUM FULL
process do the nulling for us? Vacuum works outside of normal transaction
constraints anyway...?
Also, it seems to me that at some point we are forced to break client
compatibility. Either we add attisdropped field to pg_attribute, or we use
Hiroshi's (-1 * attnum - offset) idea. Both Tom and Hiroshi have good
reasons for each of these - would it be possible for you guys to post with
your reasons for and against both the techniques. I just want to get to an
implementation specification we all agree on that can be written up and then
the coding can proceed. Maybe we should add it to the 'Postgres Major
Projects' page - and remove those old ones that have already been
implemented.
Chris
