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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Ron <ronljohnsonjr(at)gmail(dot)com>
Cc: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: [**EXTERNAL**] Re: [pgsql-admin] "Soft-hitting" the 1600 column limit
Date: 2018-06-06 23:35:20
Message-ID: CAKFQuwYfzC9yZa=tD57D361S6vBZLg=n-jrsVMpto-jjZGv=UQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, Jun 6, 2018 at 4:15 PM, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:

> On 06/06/2018 01:54 PM, Moradhassel, Kavian wrote:
>
> To my mind, it makes perfect sense for columns to persist in the table
> structure when dropped…the only question I have is whether the column would
> survive a VACUUM FULL? i.e. if the table is rewritten after the column is
> dropped, would that change things?
>
> ​A cursory skim of cluster.c, plus general reasoning, leads me to think
that the extent of the smarts of the table rewrite (for vacuum full at
least, not cluster) is to evaluate headers for visibility and omit copying
the physical tuples to the new heap. The contents of each tuple are
otherwise copied as-is (except toast pointers...). So, yes, the variant
column structures would indeed survive vacuum full and clustering
operations. There isn't any motivation to do more - a 1600​ column limit,
even with dropped columns counted, is not unreasonable - and doing more
would making an already expensive operation even more expensive (and the
risk of serious data-losing bugs in the first release is scary).

>
> Another solution would be to dump/drop/create/load *just **that table*.
>

​Any non-trivial table is generally challenging to drop due to
dependencies.​..

David J.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2018-06-06 23:44:27 Re: [**EXTERNAL**] Re: [pgsql-admin] "Soft-hitting" the 1600 column limit
Previous Message Ron 2018-06-06 23:15:42 Re: [**EXTERNAL**] Re: [pgsql-admin] "Soft-hitting" the 1600 column limit