From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | david(dot)rowley(at)2ndquadrant(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jcnaylor(at)gmail(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: PostgreSQL Limits and lack of documentation about them. |
Date: | 2018-11-28 19:17:00 |
Message-ID: | CAEfWYyyiv69WXGtTFTGcGsqkYp4HYW6xNHosSF8B1tS5JNqXQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 28, 2018 at 10:06 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> That last sentence about the dropped columns is confusing to me:
>
> + <para>
> + Columns which have been dropped from the table also contribute to the
> + maximum column limit, although the dropped column values for newly
> + created tuples are internally marked as NULL in the tuple's null
> bitmap,
> + which does occupy space.
> + </para>
>
> So the dropped columns matter, but they are null, but the nulls matter
> too. What are we really trying to say here? Maybe this:
>
> Columns which have been dropped from the table also contribute to the
> maximum column limit. Moreover, although the dropped column values for
> newly created tuples are internally marked as NULL in the tuple's null
> bitmap, the null bitmap also occupies space.
>
>
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?
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Lætitia Avrot | 2018-11-28 19:57:28 | Re: Markdown format output for psql, design notes |
Previous Message | Peter Eisentraut | 2018-11-28 18:06:16 | Re: PostgreSQL Limits and lack of documentation about them. |