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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 6, 2018 at 4:15 PM, Ron <ronljohnsonjr@xxxxxxxxx> 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.


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux