| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | scrawford(at)pinpointresearch(dot)com |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <jcnaylor(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL Limits and lack of documentation about them. |
| Date: | 2018-11-28 23:04:37 |
| Message-ID: | CAKJS1f8CukW7407P-QiB4cCfi6GrpJC6VAHDuHxGtaHbQi_SVw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 29 Nov 2018 at 08:17, Steve Crawford
<scrawford(at)pinpointresearch(dot)com> wrote:
> Both for my edification and as a potentially important documentation detail, do operations that rebuild the table such as CLUSTER or pg_repack reclaim the column space?
I've never used pg_repack, but CLUSTER will reform the tuples so that
they no longer store the actual value for the Datums belonging to the
dropped column. They'll still contain the null bitmap to mention that
the dropped column's value is NULL. The row won't disappear from
pg_attribute, so the attnums are not resequenced, therefore we must
maintain the dropped column with the NULL marking.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2018-11-28 23:17:31 | Re: COPY FROM WHEN condition |
| Previous Message | David Rowley | 2018-11-28 22:59:20 | Re: PostgreSQL Limits and lack of documentation about them. |