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.
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 |