Re: [pgsql-admin] "Soft-hitting" the 1600 column limit

David's answer is right. Basically every column added gets an index # which is not recycled.

I just want to add that a dump/restore will not bring in the history of deleted columns, thus resetting the column counter for the table.

--
Scott Ribe
scott_ribe(at)elevated-dev(dot)com
https://www.linkedin.com/in/scottribe/

> On Jun 6, 2018, at 10:51 AM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Wed, Jun 6, 2018 at 9:39 AM, nunks <nunks(dot)lol(at)gmail(dot)com> wrote:
> I reproduced this behavior in PostgreSQL 10.3 with a simple bash loop and a two-column table, one of which is fixed and the other is repeatedly dropped and re-created until the 1600 limit is reached.
>
> To me this is pretty cool, since I can use this limit as leverage to push the developers to the right path, but should Postgres be doing that? It's as if it doesn't decrement some counter when a column is dropped.
>
> ​This is working as expected. When dropping a column, or adding a new column that can contain nulls, PostgreSQL does not, and does not want to, rewrite the physically stored records/table. Thus it must be capable of accepting records formed for prior table versions which means it must keep track of those now-deleted columns.​
>
> I'm sure that there is more to it that requires reading, and understanding, the source code to comprehend; but that does seem to explain why its works the way it does.
>
> David J.
> ​