| From: | Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: DROP column: documentation unclear |
| Date: | 2010-03-09 12:16:26 |
| Message-ID: | puaauhsnad.fsf@srv.protecting.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
In article <20100308213549(dot)GB660(at)svana(dot)org>,
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>> "subsequent ... will store a null value" would imply that deleted columns
>> will still take some place, while "the space will be reclaimed ..." would
>> suggest that new rows (insert or updates in mvcc) don't have the deleted
>> column anymore - I'm not quite sure how to interpret this. What is pg
>> doing?
> What you're missing is that in postgres NULLs are stored as a bit in
> the header and there is no data. So in a sense NULLs take no space
> (well, one bit) which means both statements are true.
But if you already have eight nullable columns, the (maybe originally
non-null) column which has been dropped would cause the header to be
one byte larger, wouldn't it?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2010-03-09 12:23:06 | Re: Libpq: copy file to bytea column |
| Previous Message | zhong ming wu | 2010-03-09 12:04:19 | warm standby possible with 8.1? |