Andres Freund <and...@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