Re: ALTER TABLE on system catalogs

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: peter(dot)eisentraut(at)2ndquadrant(dot)com
Cc: andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE on system catalogs
Date: 2019-02-08 03:34:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At Fri, 08 Feb 2019 12:03:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190208(dot)120331(dot)167280496(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> By the way, I'm confused to see that attributes that don't want
> to go external are marked as 'x' in system catalogs. Currently
> (putting aside its necessity) the following operation ends with
> successful attaching a new TOAST relation, which we really don't
> want.
> ALTER TABLE pg_attribute ALTER COLUMN attrelid SET STORAGE plain;
> Might be silly, we may need another storage class, say,
> Compression, which means try compress but don't go external.
> The attached patch does that.
> - All varlen fields of pg_class and pg_attribute are marked as
> 'c'. (,, genbki.h, pg_attribute/class.h)
> - Try compress but don't try external for 'c' storage.
> (tuptoaster.c, toasting.c)
> We could remove toast relation when no toastable attribute
> remains after ATLER TABLE ALTER COLUMN SET STOAGE, but it doesn't
> seem that simple. So the storage class is for internal use only.

I found that "ALTER TABLE.. SET STORAGE plain" doesn't remove
toast relation, so it's not so bad even if compress does the

The attached 0001 is fixed from the previous version. 0002 is the


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v2-0001-Explicitly-mark-some-attributes-in-catalog-as-no-nee.patch text/x-patch 6.3 KB
v2-0002-Let-ALTER-TABLE-accept-new-storage-class-compress.patch text/x-patch 1.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-08 03:35:34 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Previous Message Kyotaro HORIGUCHI 2019-02-08 03:04:44 Re: ALTER TABLE on system catalogs