> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
