Postgres Pro
Downloads
Home   >   mailing lists

Thread: pg_class has no toast table?

pg_class has no toast table?

From
Tom Lane
Date:
Still fooling with VACUUM FULL on catalogs ... I find that a sanity
check I put in is barfing on "VACUUM FULL pg_class", because the
transient table is built with a toast table, whereas pg_class hasn't got
one.  It seems like it probably ought to have one, because either relacl
or reloptions could in principle be too big to fit without toasting
(which is exactly why AlterTableCreateToastTable thinks it should make
one for the transient table).

I have a vague feeling that we intentionally omitted a toast table for
pg_class, but I don't remember why.  Comments?
        regards, tom lane

Re: pg_class has no toast table?

From
Tom Lane
Date:
I wrote:
> Still fooling with VACUUM FULL on catalogs ... I find that a sanity
> check I put in is barfing on "VACUUM FULL pg_class", because the
> transient table is built with a toast table, whereas pg_class hasn't got
> one.  It seems like it probably ought to have one, because either relacl
> or reloptions could in principle be too big to fit without toasting
> (which is exactly why AlterTableCreateToastTable thinks it should make
> one for the transient table).

> I have a vague feeling that we intentionally omitted a toast table for
> pg_class, but I don't remember why.  Comments?

BTW, I decided not to touch this issue in the current patch --- it turns
out there are quite a few system catalogs that lack a toast table but
AlterTableCreateToastTable's rules would say to create one.  The one
that made me stop adding them was pg_largeobject.  That has a bytea
column but there are usage rules that limit the possible width of the
column, and of course AlterTableCreateToastTable doesn't know that.

So I tweaked the CLUSTER/VAC FULL logic to never add a toast table if
the original table hasn't got one.  (It can still *remove* a toast
table, as might happen after dropping a wide column for instance.)

We might still want to consider toast-ifying pg_class if anyone ever
complains about not having room for wide relacl values; but CLUSTER
shouldn't be a forcing function for such decisions.
        regards, tom lane

Re: pg_class has no toast table?

From
Simon Riggs
Date:
On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
> I wrote:
> > Still fooling with VACUUM FULL on catalogs ... I find that a sanity
> > check I put in is barfing on "VACUUM FULL pg_class", because the
> > transient table is built with a toast table, whereas pg_class hasn't got
> > one.  It seems like it probably ought to have one, because either relacl
> > or reloptions could in principle be too big to fit without toasting
> > (which is exactly why AlterTableCreateToastTable thinks it should make
> > one for the transient table).
> 
> > I have a vague feeling that we intentionally omitted a toast table for
> > pg_class, but I don't remember why.  Comments?

> BTW, I decided not to touch this issue in the current patch --- it turns
> out there are quite a few system catalogs that lack a toast table but
> AlterTableCreateToastTable's rules would say to create one.  The one
> that made me stop adding them was pg_largeobject.  That has a bytea
> column but there are usage rules that limit the possible width of the
> column, and of course AlterTableCreateToastTable doesn't know that.
> 
> So I tweaked the CLUSTER/VAC FULL logic to never add a toast table if
> the original table hasn't got one.  (It can still *remove* a toast
> table, as might happen after dropping a wide column for instance.)
> 
> We might still want to consider toast-ifying pg_class if anyone ever
> complains about not having room for wide relacl values; but CLUSTER
> shouldn't be a forcing function for such decisions.

What failure do you get if you have too many relacls or too many
reloptions? We would want it to fail cleanly. Is it enough to mark those
columns as MAIN storage?

Neither of those is worth worrying about a toast table for. Anybody with
that long a relacl hasn't thought about their admin structure enough.

-- Simon Riggs           www.2ndQuadrant.com

Re: pg_class has no toast table?

From
Tom Lane
Date:
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
>> We might still want to consider toast-ifying pg_class if anyone ever
>> complains about not having room for wide relacl values; but CLUSTER
>> shouldn't be a forcing function for such decisions.

> What failure do you get if you have too many relacls or too many
> reloptions? We would want it to fail cleanly. Is it enough to mark those
> columns as MAIN storage?

You'd get a "tuple too large" error if the tuple still didn't fit on a
page after compressing the wide columns.  We don't need to do anything
special for that.

> Neither of those is worth worrying about a toast table for. Anybody with
> that long a relacl hasn't thought about their admin structure enough.

Yeah, that's my thought also.  You'd likely start having performance
problems with thousand-item ACL lists anyway.  You should switch over to
using groups long before that.
        regards, tom lane