| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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 18:06:16 |
| Message-ID: | 23360f8f-2ddb-53f4-e756-2f380ac33b31@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Crawford | 2018-11-28 19:17:00 | Re: PostgreSQL Limits and lack of documentation about them. |
| Previous Message | Stephen Frost | 2018-11-28 17:39:28 | Re: pg_stat_ssl additions |