Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fQbk6-0008MI-Cu for pgsql-admin@arkaria.postgresql.org; Wed, 06 Jun 2018 16:57:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fQbk4-0003Hq-JR for pgsql-admin@arkaria.postgresql.org; Wed, 06 Jun 2018 16:57:00 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fQbk4-0003Hg-8j for pgsql-admin@lists.postgresql.org; Wed, 06 Jun 2018 16:57:00 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fQbk1-0000wS-5u for pgsql-admin@postgresql.org; Wed, 06 Jun 2018 16:56:58 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 05B95C167F; Wed, 6 Jun 2018 16:56:56 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KxjaU5Rzz50; Wed, 6 Jun 2018 16:56:55 +0000 (UTC) Received: from [10.190.11.133] (unknown [164.111.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 831F3C1696; Wed, 6 Jun 2018 16:56:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [pgsql-admin] "Soft-hitting" the 1600 column limit From: Scott Ribe In-Reply-To: Date: Wed, 6 Jun 2018 10:56:49 -0600 Cc: pgsql-admin , "David G. Johnston" Content-Transfer-Encoding: quoted-printable Message-Id: <15A38616-5CE2-42C4-A2F0-9FA16360761D@elevated-dev.com> References: To: nunks X-Mailer: Apple Mail (2.3445.6.18) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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@elevated-dev.com https://www.linkedin.com/in/scottribe/ > On Jun 6, 2018, at 10:51 AM, David G. Johnston = wrote: >=20 > On Wed, Jun 6, 2018 at 9:39 AM, nunks 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. >=20 > 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. >=20 > =E2=80=8BThis 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.=E2=80=8B >=20 > 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. >=20 > David J. > =E2=80=8B