Andres Freund <andres@anarazel.de> writes:
> On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
>> pg_aggregate | agginitval | text
>> pg_aggregate | aggminitval | text
> Seems like it should have a toast table, it's not too hard to imagine
> some form of aggregate to have a large initial condition.
Really? I should think the initial condition would almost always be some
spelling of "zero". Certainly nobody's ever complained of this in the
past.
>> pg_attribute | attacl | aclitem[]
>> pg_attribute | attfdwoptions | text[]
>> pg_attribute | attoptions | text[]
> Seems like it should have a toast table, but I think other people
> differed.
I think there was fear of circularity if we tried to toast pg_class
or pg_attribute. (In particular, VACUUM FULL already has its hands
full handling pg_class correctly --- dealing with a toast table too
would probably be really, uh, interesting.) Also, given the fact
that tupdescs can only store the fixed-width part of a pg_attribute
entry, having var-width fields in there at all is a pretty dubious
decision; it's way too easy to forget about that and try to fetch
them out of a tupdesc entry. I think the right approach for
potentially-long per-attribute properties is exemplified by pg_attrdef.
In any case, I don't see any of the "options" columns as things that
are likely to get long enough to be a problem. ACLs maybe could get
long, but I can only recall perhaps one thread complaining about that,
so I don't feel that there's field demand to justify toasting all the
catalogs with ACLs in them.
>> pg_largeobject | data | bytea
> We deal with this in other ways.
Right, this is one that definitely should not have a toast table.
>> pg_partitioned_table | partexprs | pg_node_tree
> Probably makes sense.
Dunno, what is a sane partitioning expression?
I don't feel that we need to insist on having a toast table for every
theoretically toastable column. The point here is to make a conscious
decision for each such column that we don't expect it to get long.
I think most of these columns are probably fine. Unsure about the
partitioning-related ones.
regards, tom lane